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Abstract 

A  recent  search  of  headlines  shows  a  high  number  of  maritime  collisions  and  accidents. 
The  USS  Hartford ,  a  nuclear  submarine,  recently  surfaced  into  an  oil  tanker  just  after  the 
running  aground  of  the  USS  Port  Royal  in  Hawaii.  Internationally,  a  French  and  British 
submarine  collided  in  the  Atlantic  Ocean.  The  high  frequency  of  these  maritime  accidents 
points  to  the  need  for  a  better  decision  support  in  ship  and  submarine  navigation. 
Towards  this  end,  this  thesis  proposes  a  mobile  decision  support  tool  to  aid  maritime 
commanders  in  maintaining  situational  awareness  and  aiding  in  navigation  and  collision 
avoidance. 

The  Mobile  Situational  Awareness  Tool  (MSAT),  specifically  designed  for  submarine 
commanders  but  extensible  to  all  maritime  settings,  provides  mobile  information  for 
health  and  status  monitoring  and  on-the-fly  path  planning  capabilities.  The  functional  and 
informational  requirements  for  MSAT  were  identified  through  an  in-depth  analysis  of 
submarine  operations,  specifically  through  a  cognitive  task  analysis.  The  MSAT  design 
incorporates  a  path  planning  algorithm  that  accounts  for  depth,  land,  visibility,  and  other 
contacts  to  propose  the  most  efficient  path  from  start  to  finish,  especially  useful  for 
navigation  in  littoral  regions.  The  MSAT  also  provides  health  and  status  monitoring 
capabilities,  tracking  many  of  the  important  systems  across  a  submarine  to  provide 
information  to  the  commander,  as  well  as  maintain  high  situational  awareness. 

Human  subject  experiments  showed  that  when  compared  to  paper  charts,  the  navigation 
tool  in  the  MSAT  performs  significantly  better  with  regards  to  both  path  length  and  the 
time  it  takes  to  plan  a  new  path.  For  health  and  status  monitoring,  a  survey  of  current  task 
times  revealed  potential  savings  by  the  MSAT  by  decreasing  both  the  average  and 
variability  of  task  time.  By  reducing  the  number  of  physical  movements  needed  by 
commanders  through  the  use  of  a  mobile  tool,  time  is  saved  that  can  be  used  for  task 
reallocation,  or  promote  a  change  in  task  flow. 

There  are  many  potential  benefits  for  both  the  Navy  and  the  commercial  maritime 
community  that  the  MSAT  can  provide.  However,  before  the  MSAT  can  become 
operational,  there  are  some  system  implementation  issues  that  must  first  be  addressed. 
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These  range  from  an  analysis  of  the  hardware  and  software  required,  to  the  changes  in 
training  that  might  come  from  the  addition  of  a  new  tool.  Future  work  is  needed  in  this 
area  to  help  move  forward  so  that  the  benefits  can  be  realized  across  the  maritime 
community. 

Thesis  Supervisor:  Mary  L.  Cummings 

Title:  Associate  Professor  of  Engineering  Systems 
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1.  Introduction 


Submarines  play  a  vital  role  in  the  nation’s  defense,  but  not  without  problems.  Recent 
U.S.  Navy  collision  and  grounding  incidents  involving  the  USS  Greeneville,  USS  San 
Francisco ,  USS  Newport  News,  and  more  recently  the  USS  Hartford  along  with 
numerous  other  collisions  have  highlighted  the  difficulty  of  submarine  navigation 
operations  (Burns,  2009;  Fishel,  2009;  Hamilton,  2005;  NTSB,  2001;  Riley,  2009; 
Scutro,  2007).  These  accidents  occurred  for  a  variety  of  reasons,  including  outdated  paper 
charts  and  lack  of  information  accessibility,  in  all  cases  leading  to  a  lack  of  situational 
awareness  (SA)  by  the  commander. 


/  \ 

Bridge 

Crew  Quarters 

Engine  Room 

A 

Control  Room 

Wardroom 

u . 

Weapons  Room 

Figure  1:  Submarine  Layout  (Side  View) 

Situational  awareness  has  been  a  popular  topic  among  both  civilian  and  military  operators 
ever  since  the  term  was  first  coined  by  the  military  (Bovier,  1997).  SA,  as  defined  by 
Endsley  (2000),  refers  to  the  perception,  comprehension,  and  projection  of  surrounding 
elements  in  an  environment.  Although  the  term  is  often  cited  in  aviation  contexts,  the 
concept  of  understanding  one’s  surroundings  and  being  able  to  predict  the  future  is 
important  across  many  domains.  The  submarine  environment  is  one  realm  where 
commanders  spend  a  great  deal  of  time  analyzing  their  surroundings  to  build  their 
situational  awareness.  The  commander  is  in  charge  of  safety  and  directs  the  submarine’s 
activities,  and  he  is  responsible  for  these  no  matter  where  he  is  physically  located  on  the 
sub.  The  problem  is  that  the  information  needed  to  ensure  safety  and  direct  the  activities 
of  the  sub  is  only  available  in  the  control  room,  notionally  depicted  in  Figure  1.  While 
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checking  on  the  engine  room  or  eating  meals  in  the  wardroom,  the  available  information 
is  limited. 

To  check  the  detailed  information,  officers  must  go  to  the  control  room.  The  control  room 
on  a  nuclear  submarine  is  where  multiple  information  sources  (including  sonar,  radar, 
Global  Positioning  System  (GPS),  and  visual  lookouts)  are  presented  to  the  commander 
through  surrounding  displays.  This  information  is  disjointed,  and  during  complex 
maneuvers,  the  commander  may  not  have  the  full  picture  until  it  is  too  late.  This 
separation  of  information  limits  the  commander’s  SA,  increasing  the  risk  of  collisions  or 
other  problems.  This  was  the  case  with  the  USS  Greenville ,  which  collided  with  a 
Japanese  fishing  vessel  while  demonstrating  its  capabilities  in  the  Pacific  Ocean  in  2001 
(NTSB,  2001).  During  a  series  of  turns  and  depth  changes,  the  commanding  officer  lost 
SA,  and  ran  into  the  Japanese  vessel  while  surfacing,  resulting  in  the  loss  of  nine  lives. 
The  other  accidents  mentioned  above  also  relate  to  a  lack  of  SA  and  are  discussed  in 
further  detail  in  Chapter  2. 

Inside  the  modem  submarine,  a  wealth  of  technology  is  available,  but  rapid  development 
has  led  to  the  paradox  of  technology,  where  the  increased  functionality  decreases  the  ease 
of  use  (Norman,  1988).  The  amount  of  information  available  surpasses  the  commander’s 
ability  to  monitor  and  extract  the  necessary  information,  which  leads  to  the  delegation  of 
monitoring  tasks  to  others.  Under  this  current  operational  paradigm,  critical  information 
can  be  missed  or  lost  during  communication,  assimilation,  or  synthesis.  This  makes  it 
difficult  for  the  commander  to  create  an  accurate  mental  model  and  maintain  appropriate 
levels  of  SA.  With  nuclear  submarines  costing  billions  of  dollars  and  supporting  a  crew 
of  over  100  people,  it  is  important  to  ensure  safety  of  operations  for  both  the  crew  and  the 
asset  itself  (Wiltrout,  2008).  Therefore,  there  is  a  need  to  consider  new  ways  of 
presenting  information  to  the  commander  to  not  only  enhance  safety  through  improved 
SA,  but  to  also  establish  more  efficient  systems  management. 

One  way  supervisors  of  complex  systems  can  handle  the  overwhelming  amount  of 
information  is  with  decision  support  tools  (Delic,  Douillet,  &  Dayal,  2001).  As 
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technology  provides  an  increasing  amount  of  information  to  the  operator,  these  tools  act 
as  aids  in  condensing  information  to  display  it  in  an  efficient  manner.  There  are  many 
different  technologies  used  in  the  commercial  maritime  environment  to  provide 
navigation  decision  support,  such  as  electronic  charts  and  commercial  radar  systems  with 
automatic  trajectory  recommendations.  Electronic  chart  displays  and  Automatic 
Identification  Systems  (AIS)  have  been  commonplace  for  years  in  commercial  maritime 
environment,  but  were  not  approved  for  military  operations  until  2008  (Rhodes  & 
Delaney,  2008).  AIS  broadcasts  commercial  and  merchant  ship  information,  including 
position,  speed,  and  course  to  all  surrounding  boats.  With  electronic  charts,  the  AIS 
information  can  be  displayed  to  the  operator.  These  tools  can  be  beneficial  to  the 
submarine  community  in  solving  some  of  the  SA-related  problems  by  aggregating  and 
highlighting  critical  information.  However,  these  tools  are  localized  to  the  control  room, 
are  not  integrated  to  aggregate  information,  and  cannot  be  monitored  at  all  times  by  the 
commander  himself  who  may  leave  the  control  room  at  times.  A  revolutionary  way  to 
support  the  commander  is  to  make  the  critical  information  available  in  an  integrated 
fashion  to  the  commander,  independent  of  his  location  on  the  submarine. 

Along  with  the  need  for  better  presentation  of  information,  the  need  to  be  mobile  is  also 
increasing  for  operators  in  all  environments.  Mobile  text  messaging,  email,  Internet,  and 
even  stock  trading  tools  are  increasing  in  popularity.  Small  Unmanned  Aerial  Vehicles 
(UAVs)  can  now  be  controlled  using  handheld  devices  offering  full  functionality  (Kutta 
Consulting,  2007).  The  increased  capabilities  of  mobile  tools  can  provide  help  in  the 
complex  submarine  environment.  Mobile  tools  would  increase  flexibility  by  allowing  the 
commander  to  stay  active,  while  presenting  critical  information  in  the  quickest  way 
possible. 

Via  an  in-depth  analysis  of  submarine  operations,  this  research  identified  design 
requirements  for  a  mobile  decision  support  tool  for  commanders.  A  decision  support  tool 
was  developed  based  on  the  identified  requirements.  A  human  subject  experiment  was 
conducted  to  test  the  effectiveness  and  acceptance  of  this  tool,  showing  that  operators 
performed  navigation  tasks  more  effectively  and  in  less  time  with  the  tool  when 
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compared  to  paper  and  pencil  methods.  While  this  thesis  focuses  specifically  on 
submarine  operations,  any  supervisor  of  time -pressured,  complex  systems  could 
potentially  benefit  from  this  research. 

1.1  Problem  Statement 

The  task  of  commanding  a  submarine  is  a  complicated  process,  particularly  due  to  the 
large  amount  of  data  intake  and  the  bottleneck  of  information  going  to  the  commander. 
Information  displays  are  becoming  increasingly  important  as  new  technologies  aid  in 
building  the  surrounding  picture.  For  a  submarine  commander,  there  are  many  different 
tasks  that  must  be  constantly  balanced,  from  navigation  and  weapons  control  to 
management  of  the  crew  and  planning  future  paths.  These  high  cognitive  requirements 
demand  intuitive  displays  that  present  critical  information  to  the  commander  for 
immediate  decisions.  By  presenting  this  information  on  a  mobile  device,  the  commander 
would  gain  a  further  benefit  by  not  being  confined  to  the  control  room. 

1.2  Research  Objectives 

In  order  to  address  the  problem  statement,  the  overarching  goal  of  this  research  is  to 
develop  a  mobile  decision  support  tool  for  submarine  commanders.  This  goal  is 
addressed  through  the  following  research  objectives: 

•  Objective  1.  Study  current  submarine  operations  and  determine  the  causes 
for  operational  inefficiencies.  The  first  step  in  this  process  is  to  determine  how 
submarine  operations  are  conducted,  what  the  goals  are,  and  determine  the  causes 
of  recent  accidents.  Chapter  2  discusses  background  information  on  the  submarine 
environment,  and  some  current  research  being  conducted  to  help  address  these 
problems. 

•  Objective  2.  Study  the  cognitive  strategies  employed  by  submarine  officers 
during  operations.  In  order  to  achieve  this  objective,  a  cognitive  task  analysis 
(CTA)  was  conducted.  The  CTA  was  used  to  identify  the  information  inputs  and 
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decision  processes  involved  in  both  navigation  and  health  and  status  monitoring. 
This  process  and  its  results  are  outlined  in  Chapters  3. 

•  Objective  3.  Develop  a  mobile  decision  support  tool  for  use  in  maritime 
domains.  Based  on  the  results  of  the  CTA,  a  mobile  decision  support  tool  was 
designed  for  the  submarine  environment,  the  Mobile  Situational  Awareness  Tool 
(MSAT).  This  tool  addresses  a  subset  of  the  overall  submarine  functions  listed  in 
Chapter  2.  A  discussion  of  the  design  and  functionality  of  the  display  can  be 
found  in  Chapter  3. 

•  Objective  4.  Evaluate  the  effectiveness  of  the  new  decision  support  tool  for  the 
maritime  environment.  Human  subject  testing  was  conducted  in  order  to  fulfill 
this  objective.  Civilian  maritime  operators,  along  with  members  from  the  Navy 
and  Coast  Guard,  were  tested  and  interviewed  to  gain  information  on  how  well 
the  task  of  path  planning  could  be  augmented  by  automation.  Subjects  were  also 
questioned  as  to  how  health  and  status  monitoring  on  the  mobile  display  would 
affect  operations  as  compared  to  current  methods.  Finally,  subjects  filled  out  a 
questionnaire  and  were  interviewed  to  determine  their  attitudes  towards  the 
mobile  tool,  in  particular  trust  and  confidence.  Results  of  these  tests  are  provided 
in  Chapter  5. 

•  Objective  5.  Determine  the  system  implementation  issues  involved  in 
integrating  a  mobile  tool  into  the  current  submarine  operating  environment. 

The  integration  of  any  new  technology  involves  changes  beyond  the  tool  itself. 
Training,  manning,  responsibilities  and  workflow  can  all  be  affected.  Chapter  6 
discusses  the  issues  that  must  be  overcome  for  system  implementation,  from 
software  and  hardware  to  the  effects  on  operations  themselves. 
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1.3  Thesis  Organization 

This  thesis  is  organized  into  seven  chapters: 

•  Chapter  1,  Introduction ,  provides  the  motivation  for  this  research,  research 
questions,  and  the  research  objectives  of  this  thesis. 

•  Chapter  2,  Background ,  reviews  current  submarine  operations  and  discusses  some 
of  the  shortcomings.  Submarine  functions  are  broken  down  and  described  in  order 
to  generate  design  requirements.  This  chapter  also  discusses  how  mobile 
technology  has  developed  in  other  fields. 

•  Chapter  3,  Design  of  the  Mobile  Situational  Awareness  Tool,  explains  the  method 
used  for  developing  the  MS  AT.  After  detailing  the  Cognitive  Task  Analysis 
(CTA),  this  chapter  discusses  the  process  of  determining  information 
requirements  and  finishes  with  a  description  of  how  the  final  interface  works  to 
meet  these  needs. 

•  Chapter  4,  Evaluation  Methodology,  discusses  how  the  MSAT  was  compared  to 
current  submarine  operations,  and  what  assessment  strategy  was  used  to  gauge  the 
effects  of  the  MSAT.  An  experiment  comparing  paper  and  pencil  navigation 
versus  the  MSAT  was  performed,  and  results  are  presented. 

•  Chapter  5,  Results  and  Discussion,  explains  the  results  of  the  testing  including  the 
survey  feedback  and  trust  analysis. 

•  Chapter  6,  System  Implementation,  discusses  issues  with  the  implementation  of 
this  technology.  Manning  issues,  task  allocation,  and  software  and  hardware 
requirements  are  discussed  as  they  pertain  to  the  addition  of  a  tool  such  as  the 
MSAT  to  current  operating  environments. 

•  Chapter  7,  Conclusion,  reviews  the  answers  to  the  research  questions,  discusses 
how  the  MSAT  fits  into  the  future  submarine  environment,  and  suggests  areas  for 
future  research. 
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2.  Background 

This  chapter  provides  information  on  current  submarine  operations  including  sea  surface 
operations.  Historical  shortcomings  are  discussed,  along  with  design  changes  provided  by 
the  newest  class  of  submarines,  the  Virginia  class.  Previous  research  into  path  planning, 
automation,  display  design  and  decision  support  is  also  discussed.  Finally,  mobile 
command  devices  and  technology  are  introduced  to  demonstrate  how  the  advances  can 
help  a  commander  to  remain  in  the  loop  without  being  tied  to  a  specific  location. 

2.1  Current  Submarine  Operations 

The  Navy  operates  two  different  types  of  submarines,  ballistic  missile  submarines  and 
attack  submarines.  The  most  recent  model  is  the  Virginia  attack  class  (Pike,  2008),  which 
will  be  referenced  throughout  this  thesis  as  it  represents  the  current  state-of-the-art  in 
submarine  technology. 

All  of  the  Navy’s  combatant  submarines  are  nuclear-powered,  which  provides  superior 
capability  in  terms  of  range  and  power  as  well  as  increased  responsibility.  Submarine 
operations  tend  to  have  a  high  stress  environment,  partly  due  to  the  onboard  nuclear 
reactor.  Information  regarding  the  reactor,  the  cooling  systems,  as  well  as  atmospheric 
levels  throughout  the  submarine  requires  constant  monitoring.  This  information,  along 
with  updates  on  surrounding  ships  (contacts)  and  weather  is  continuously  passed  up 
through  several  layers  of  personnel  to  the  commanding  officer  (CO),  who  is  responsible 
for  everything  and  everyone  on  the  submarine. 

One  commonality  in  all  military  operations  is  the  underlying  rank  structure  that  helps  to 
define  roles  and  responsibilities.  The  hierarchy  on  a  submarine  helps  to  define  clear 
positions  for  each  member  and  prevents  overlapping  duties  and  tasks.  The  flow  of 
information  is  highly  vertical,  with  sensor  operators  such  as  sonar  and  radar  watchmen 
passing  information  up  a  hierarchical  chain  of  command  to  the  commander  of  the 
submarine,  who  then  builds  his  mental  model  based  on  the  various  information  inputs. 
Most  of  this  monitoring  occurs  in  different  stations  in  the  control  room,  where  various 
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crew  members  process  information.  The  CO  is  then  notified  of  any  important  updates  as 
the  submarine  tracks  along  its  course. 


Today’s  submarines  are  capable  of  many  different  mission  types,  from  surveillance  and 
intelligence  to  sea  denial  and  precision  strike,  and  each  mission  type  requires  its  own 
specific  information.  During  each  mission,  priorities  change,  as  speed  is  traded  for 
silence,  or  an  offensive  position  for  a  defensive  one.  The  information  that  becomes  most 
important  for  the  commander  changes  (Norfolk  Naval  Base,  2008).  This  information 
comes  from  many  stations  and  people  across  the  submarine,  in  support  of  many  different 
functions.  Figure  2  shows  a  mapping  of  how  these  functions  and  missions  are  related. 


In  Figure  2,  basic  operating  functions  are  shown  on  the  right  (navigate,  communicate,  and 
operate),  as  these  are  required  for  all  of  the  mission  types  shown  in  the  middle 
(surveillance  special  operations,  weapons  delivery).  All  of  these  processes  are 
accomplished  with  different  information  requirements  and  control  inputs.  Furthermore, 
regardless  of  the  specific  function,  the  commander  must  also  be  constantly  involved  in 
health  and  status  monitoring  of  all  systems,  to  ensure  that  the  safety  of  the  ship  remains 
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intact.  In  the  identification  of  submarine  functions,  future  missions  using  UUVs  were  also 
considered,  as  this  is  a  function  likely  to  be  needed  in  the  future  (Bhattacharjee,  2007). 

Both  between  and  during  different  missions,  submarines  come  to  the  surface  to  update 
information  systems.  This  allows  the  submarine  to  maintain  contact  with  other  ships,  as 
well  as  link  to  Global  Positioning  System  (GPS)  and  radio  communication.  During 
surface  navigation,  there  is  a  great  deal  of  effort  put  into  path  planning  and  navigation,  as 
the  likelihood  of  surrounding  contacts  increases  and  collision  avoidance  becomes  a  top 
priority  in  littoral  regions  (Lebkoswki  et  al.,  2005).  Although  navigation  tasks  are  critical 
to  the  safety  of  the  submarine,  they  are  still  currently  completed  with  paper  charts  and 
pencils  on  many  of  the  Navy  submarines  that  do  not  yet  have  Electronic  Chart  Displays 
(ECDIS)  (Wiltrout,  2008).  One  of  the  advantages  of  the  ECDIS  is  the  ability  to  overlay 
information  such  as  depth  and  surrounding  obstacles  directly  on  the  chart.  Electronic 
Chart  Displays  are  currently  available  on  most  civilian  commercial  ships,  but  until 
recently  they  were  not  approved  as  a  primary  means  of  navigation  for  military  ships. 

In  the  control  room,  there  is  a  crew  of  anywhere  between  eight  and  eighteen  personnel, 
each  member  passing  critical  information  to  their  direct  supervisor,  until  the  information 
reaches  the  CO.  Figure  3  shows  the  typical  layout  in  the  new  Virginia  Class  submarines. 
In  the  front  (top  of  Figure  3),  a  pilot  and  co-pilot  are  in  charge  of  driving  the  submarine 
using  inputs  on  a  touch  screen  display.  The  Officer  On  Deck  (OOD)  is  the  officer  in 
charge  of  the  control  room,  and  the  position  rotates  through  crew  members,  including 
junior  and  senior  officers.  Whoever  occupies  the  position  gives  navigation  and 
monitoring  orders  throughout  his  shift.  In  the  front  of  the  submarine,  the  pilot  is  in  charge 
of  monitoring  any  warnings  from  the  engine  or  pressure  systems  and  following  the 
commands  of  the  OOD. 

There  is  also  a  team  of  people  who  search  the  surrounding  waterways  for  other  contacts. 
At  one  station,  a  team  of  sonar  operators  listens  for  other  boats,  and  at  another,  radio  and 
radar  operators  do  the  same.  There  is  also  a  person  checking  visually  for  other  boats 
using  photonics,  and  all  of  this  information  is  sent  to  the  fire  control  stations  where 
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contacts  are  monitored.  The  contact  coordinator  tracks  these  contacts  as  the  pilot 
navigates  along  the  path.  Future  paths  are  planned  by  the  navigator,  and  put  onto  a  chart 
by  the  plotter.  The  contact  coordinator  tracks  information  using  the  Voyage  Management 
System  (VMS),  which  is  an  integrated  ECDIS  display,  discussed  further  in  section  2.1.3. 
All  personnel  work  together  sending  information  to  the  OOD  to  keep  the  submarine  out 
of  harm’s  way. 


Figure  3:  Virginia  Class  Control  Room  (Connor,  1999) 


During  all  operations,  the  commander  and  the  executive  officer  (XO)  remain  at  the  top 
level  of  command,  with  the  XO  aiding  the  commander  and  serving  as  the  second  in 
command.  During  complex  scenarios,  the  CO  or  XO  will  fill  the  role  of  the  OOD.  This 
information  flow  is  represented  in  Figure  4.  With  so  many  information  sources  and 
players  involved,  the  control  room  becomes  a  very  high  stress  area,  and  the  shortcomings 
are  discussed  in  the  next  section. 
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2.1.1  Shortcomings 

This  section  describes  some  of  the  problems  within  the  submarine  community  addressed 
through  this  research.  First,  a  discussion  of  recent  submarine  crashes  is  presented, 
followed  by  some  of  the  problems  with  current  navigation  processes.  Operations  are 
discussed  with  respect  to  the  crew,  noting  the  need  for  officers  to  be  mobile,  and  how  this 
mobility  can  add  difficulty  to  maintaining  the  flow  of  information.  Finally,  the  design  of 
the  submarine  is  discussed  with  regards  to  the  current  problems  of  adding  new 
technologies. 

Over  the  past  few  years,  there  have  been  various  accidents  that  highlight  difficulties  in 
submarine  navigation.  Two  specific  examples  are  the  Los  Angeles  Class  USS  Greeneville 
and  the  USS  San  Francisco.  The  USS  Greeneville  surfaced  into  a  Japanese  fishing  vessel 
in  2001,  and  the  cause  of  the  accident  was  the  inadequate  interaction  and  communication 
among  senior  members  of  the  combat  systems  team  (NTSB,  2001).  Problems  with  the 
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equipment  used  to  track  contacts  led  to  the  eventual  incomplete  contact  picture,  with 
missing  information  on  the  position  of  one  of  the  neighboring  ships  (NTSB,  2001).  The 
USS  San  Francisco  also  suffered  from  a  collision,  running  into  a  sea  mount  southeast  of 
Guam.  This  collision  was  the  result  of  outdated  paper  charts,  which  were  not  accurate  for 
the  changing  depths  of  the  sea  floor  (Hamilton,  2005).  For  instance,  the  Notice  to 
Mariners  (a  document  used  to  update  paper  charts)  including  updates  on  this  sea  mount 
was  over  58  pages  long,  covering  hundreds  of  changes.  This  update  was  also  only  one  of 
fifteen  given  during  the  calendar  year,  making  it  very  difficult  to  stay  current. 

More  recently,  three  accidents  have  occurred  in  the  military  maritime  community, 
bringing  added  attention  to  the  current  safety  of  operations.  On  February  5,  2009,  the 
USS  Port  Royal  ran  aground  off  the  coast  of  Hawaii,  while  navigating  in  shallow  water 
(Riley,  2009).  The  Port  Royal  is  a  Ticonderoga-class  guided  missile  cruiser,  with  a  cost 
of  $1  billion  to  build  and  a  crew  of  360  (Riley,  2009).  Less  than  two  weeks  later,  the 
British  HMS  Vanguard  and  the  French  Le  Triomphant  collided  in  the  Atlantic  Ocean. 
Both  were  operating  in  the  same  area  and  were  unable  to  detect  each  other.  After  the 
crash,  the  French  submarine  did  not  realize  what  it  had  hit,  and  determined  it  was  the 
British  submarine  only  after  returning  to  port  (Burns,  2009).  The  third  accident  was  a 
collision  between  a  submarine,  the  USS  Hartford ,  and  another  Navy  ship,  the  USS  New 
Orleans,  which  collided  when  the  submarine  was  surfacing  in  April,  2009  (Raphael, 
2009).  The  full  details  of  the  collisions  have  not  yet  been  released,  but  the  frequency  of 
these  incidents  highlights  the  need  to  increase  the  safety  of  maritime  navigation 
operations. 

These  accidents  illustrate  that  outdated  technologies,  and  also  poor  workflow  processes 
contribute  to  navigation  problems.  Typical  submarine  workdays  are  18  hours  long,  with 
12  hours  on  and  6  hours  off.  This  leaves  little  time  for  sleep  or  rest,  and  also  means  many 
shift  changes  and  position  switches.  In  a  submarine,  the  information  needs  to  be 
constantly  passed  to  shift  replacements,  and  the  crew  must  maintain  constant  vigilance  to 
prevent  information  from  being  lost  between  shift  changes.  The  CO  is  also  very  active, 
moving  around  to  different  parts  of  the  ship,  always  ready  to  be  contacted  by  the  control 
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room  if  a  situation  arises.  Although  the  Virginia  Class  is  only  about  100  yards  from  end 
to  end,  the  series  of  turns  and  hatches  inside  a  submarine  separate  the  compartments,  and 
slow  movement.  This  can  make  it  difficult  for  the  CO  to  get  up-to-date  information, 
depending  on  where  on  the  ship  he  is.  Even  if  there  is  an  intercom  system,  the  amount  of 
information  that  can  be  transferred  through  broadcasting  is  limited.  It  is  also  difficult  to 
present  information  clearly  without  a  visual  picture,  which  keeps  the  intercom  from  being 
used  if  it  can  be  avoided.  Moreover,  broadcasting  over  the  intercom  is  infeasible  when 
silence  is  needed  for  operations. 

The  flow  of  information  itself  can  also  be  limiting,  due  to  the  rank  hierarchy  used  in  the 
submarine,  the  flow  of  information  is  typically  from  bottom  to  top,  with  limited 
horizontal  communication.  For  instance,  in  the  straits  of  Hormuz,  the  attack  submarine 
USS  Newport  News  collided  with  the  Japanese  merchant  vessel  Mogamigawa  in  2007 
when  crew  members,  who  were  assembling  the  contact  picture,  did  not  pool  all  of  the 
information,  resulting  in  the  collision  of  the  two  vessels  (Scutro,  2007).  Each  operator 
saw  only  a  small  part  of  the  information,  and  rather  than  comparing  data,  each  member 
disregarded  it  as  noise.  This  lack  of  information  sharing  can  also  be  seen  in  the  system 
design  as  well,  as  the  relatively  new  Automatic  Identification  System  (AIS),  an 
automated  system  used  to  track  and  identify  nearby  ships,  has  been  added  to  submarine 
control  rooms  without  changing  the  information  on  the  fire  control  displays.  This  means 
that  rather  than  sending  the  contact  information  automatically  into  the  rest  of  the  system, 
AIS  information  stays  on  a  separate  screen  unless  manually  entered  into  the  fire  control 
displays. 

This  lack  of  information  integration  is  a  general  trend  in  the  submarine  community, 
where  new  technologies  are  added  without  re-designing  the  surrounding  systems. 
Although  the  submarine  community  has  started  to  integrate  new  commercialized  products 
such  as  Furuno  Radar  and  AIS,  which  simplify  the  tasks  of  monitoring  and  tracking 
contacts,  these  systems  are  often  added  as  afterthoughts.  Designing  the  system  as  a  whole 
would  allow  the  full  functionality  to  be  achieved,  incorporating  AIS  data  and  radar 
positioning  across  all  stations  from  contact  coordinator  and  fire  control  to  the  plotter. 
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2.1.2  Virginia  Class  Updates 

The  Virginia  class  comes  with  many  technological  advancements,  such  as  photonic  masts 
that  replace  the  standard  periscope  with  an  electronic  camera,  and  a  reactor  that  lasts  the 
life  of  the  submarine  (Pike,  2008).  Although  there  are  many  improvements  over  older 
submarine  classes,  there  are  still  shortcomings.  For  one,  atmospheric  levels  must  be 
tracked  hourly  by  hand,  and  this  task  is  done  using  a  mobile  handheld  device.  This  device 
is  then  synchronized  with  a  computer  before  the  information  is  actually  entered  in  the 
system,  and  even  then,  trend  analysis  is  not  available  in  any  visual  form.  There  are  also 
problems  with  the  warning  systems,  as  there  is  no  ability  to  set  custom  warning  levels. 
Only  pre-programmed  levels  can  be  used,  which  is  sometimes  not  when  the  commander 
wants  the  actual  alarm  to  go  off.  These  and  additional  shortcomings  will  be  discussed  in 
Chapter  3,  which  details  the  results  of  a  cognitive  task  analysis. 

2.1.3  Voyage  Management  System 

One  important  update  seen  on  the  Virginia  class  is  the  Voyage  Management  System 
(VMS).  Until  the  emergence  of  the  Voyage  Management  System,  the  Navy  required  all 
navigation  to  be  performed  using  paper  charts.  The  VMS  is  the  system  used  by  the  US 
Navy  to  replace  the  old  paper  and  pencil  navigation  methods.  The  VMS  is  an  ECDIS  that 
takes  information  from  the  Navigator,  radar,  GPS,  and  Fire  Control  and  incorporates 
information  into  a  single  view.  This  view  shows  the  ownship  location  and  heading,  as 
well  as  other  contacts  and  their  courses.  It  also  leverages  the  strength  of  automation  to 
perform  electronic  dead  reckoning  and  sound  alarms  when  limits  are  breached.  The  VMS 
is  a  powerful  tool  and  has  greatly  simplified  the  task  of  navigation  by  reducing  the  work 
for  the  human  and  presenting  a  refined  picture  of  surroundings.  However,  the  VMS  still 
has  problems.  Through  interviews  discussed  more  in  detail  in  Chapter  3,  issues  with 
redundant  warnings  and  system  lockups  are  still  present. 

2.2  Previous  Research 

One  question  within  this  research  is  how  to  increase  safety  and  efficiency  for  surface 
operations.  Surface  operations  were  chosen  as  a  focus  area  due  to  the  increased 
complexity  that  comes  with  operating  a  submarine  on  the  surface,  i.e.,  there  are  many 
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more  contacts  on  the  surface  than  under  the  water.  In  addition,  the  focus  on  surface 
operations  allows  for  greater  generalizability  to  other  maritime  settings.  The  following 
sections  contain  information  on  current  research  and  developments  relating  to  submarine 
navigation  operations  and  the  use  of  automation  in  support  of  these  tasks. 

2.2.1  Automation 

As  maritime  technology  continues  to  advance,  tasks  previously  conducted  by  the  human 
can  now  be  automated.  This  can  equate  to  long-term  cost  savings,  reduced  manning,  and 
more  consistent  and  predictable  outputs.  With  any  use  of  automation,  it  is  important  to 
define  roles  to  keep  the  right  balance  of  workload  and  decision  making  power.  When  task 
allocation  is  done  well,  the  system  is  able  to  leverage  the  strengths  of  the  human  mind 
with  the  power  of  automation  to  minimize  human  weaknesses  (Cummings  &  Brani, 
2009).  It  is  also  important  for  the  user  to  understand  what  the  automation  is  doing  and 
why,  which  leads  to  predictable  outputs  regardless  of  the  level  of  automation  (Billings, 
1997).  In  general,  research  has  shown  that  intermediate  levels  of  automation  that  keep  the 
user  involved  work  well  in  situations  allowing  for  human  in  the  loop  control  (Endsley  & 
Kaber,  1999). 

For  the  crew  on  a  submarine,  automation  can  provide  many  benefits.  Sensors  that  will 
warn  the  crew  if  critical  levels  are  reached  can  do  many  of  the  monitoring  tasks  that  are 
currently  done  by  hand,  such  as  checking  pressure  gauges  and  monitoring  air  levels. 
Automation  can  be  especially  useful  for  path  planning,  where  automation  performs  skill 
and  rule  based  tasks  such  as  mapping  and  connecting  waypoints  so  humans  only  have  to 
focus  on  knowledge-based  reasoning  (Rasmussen,  1983).  Previous  research  has  shown 
that  leveraging  computer-generated  paths  can  lead  to  more  efficient  paths  when 
compared  to  human  generated  paths  (Marquez  et  al.,  2005).  This  research  points  to  the 
benefits  of  using  automation  for  path  planning  when  there  is  a  clear  set  of  rules  for  the 
computer  to  follow.  This  is  the  case  with  maritime  navigation,  where  obstacles, 
constraints,  and  navigation  rules  dictate  the  possible  solutions.  Automation  can  quickly 
search  possible  paths  to  determine  the  most  efficient  based  on  the  user’s  needs. 


27 


Other  research  has  shown  that  automation  is  especially  helpful  for  time  critical  situations 
(Johnson  et  al.,  2002).  On  a  submarine  navigating  through  the  littoral  regions  where 
contact  density  is  high,  time  plays  a  major  role  in  route  planning.  In  addition,  further 
studies  indicate  that  automation  should  propose  solutions,  not  just  check  the  feasibility  of 
a  user’s  input  (Chen  &  Pritchett,  2001).  By  providing  submarine  officers  with  possible 
path  choices,  navigation  decisions  can  be  made  quickly,  while  still  keeping  the  human 
operator  involved  in  the  decision  making.  Following  these  guidelines  in  the  maritime 
navigation  setting  can  lead  to  a  successful  path  planner  that  creates  efficient  paths  in  a 
short  amount  of  time. 

When  designing  automation,  one  key  factor  that  must  be  considered  is  how  trustworthy 
the  automation  is.  When  humans  offload  work  to  a  computer,  they  are  doing  so  under  the 
premise  that  the  computer  system  can  be  trusted  to  perform  the  task  as  expected.  When 
developing  a  decision  support  tool,  it  is  essential  that  the  design  facilitates  trust,  so  that 
the  user  is  willing  to  use  the  tool  to  its  full  potential  (Muir,  1987).  In  particular,  users  are 
more  likely  to  trust  a  system  that  proves  reliable  in  complex  situations  (Lee  &  See,  2004). 
Distrust  may  lead  to  system  disuse  and  over-trust  may  lead  to  over-reliance  on 
automation  (Parasuraman  &  Riley,  1997).  As  a  user  increasingly  uses  automation,  one 
negative  trend  is  a  decrease  in  the  user’s  self  confidence  (Moray,  Inagaki,  &  Itoh,  2000). 
If  a  system  is  unreliable,  and  presents  poor  information,  this  is  also  a  problem,  as 
operators  will  avoid  the  automation.  With  previous  research  in  mind,  it  is  important  to 
design  a  decision  support  tool  that  presents  the  user  with  reliable  automation,  in  a  timely 
manner,  while  keeping  the  user  involved  in  the  final  decision.  This  can  help  to  build  trust 
and  self-confidence,  as  the  user  can  continue  to  be  part  of  the  decision  making  process. 
Chapter  4  addresses  these  issues  in  more  detail. 

2.2.2  Collision  Avoidance 

Many  researchers  have  built  on  the  strengths  of  automation  to  aid  in  collision  avoidance 
(Lebkoswki  et  al.,  2005).  Over  the  years,  the  number  of  accidents  in  the  maritime 
community,  both  collisions  and  groundings,  have  decreased  (Tiblin,  1990).  Many 
changes  have  been  implemented  to  aid  in  navigation  safety,  from  new  licensing  programs 
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and  increased  traffic  separation  zones  to  harbor  traffic  control  systems  that  moderate 
congestion  (Tiblin,  1990).  However,  one  of  the  largest  contributions  to  maritime  safety  is 
likely  be  the  electronic  revolution  at  sea  (Tiblin,  1990). 

The  benefit  of  systems  that  can  automatically  track  and  plot  collision  situations  has  been 
popular  for  nearly  20  years,  with  some  of  the  first  research  published  in  1990  discussing 
Predicted  Areas  of  Danger  (PAD)  (Tiblin,  1990).  This  research,  which  expanded  on  dead 
reckoning  observations  to  add  uncertainty  around  each  ship,  showed  a  clear  benefit  for 
ships  that  used  Automatic  Radar  Plotting  Assist  (ARPA).  ARPA  could  predict  where 
possible  collisions  would  occur,  based  on  current  course  and  speeds.  ARPA  and  similar 
systems  are  in  many  ships  today,  where  radar  is  used  to  predict  contact  locations  over 
time  and  notify  the  user  if  he  or  she  is  on  a  collision  course.  ARPA  was  then  expanded  to 
incorporate  an  evolutionary  algorithm  to  aid  in  collision  avoidance  that  accounts  for  other 
variables  in  the  navigation  picture,  such  as  water  currents,  weather,  and  the  size  of  each 
vessel  (Smierzchalski  &  Michalewicz,  1998).  This  evolutionary  algorithm  for  navigation 
was  then  tested,  and  it  successfully  accounted  for  other  contacts  and  obstacles  to  present 
a  safe  trajectory  in  collision  situations  using  sample  data  inputs  (Lebkoswki  & 
Dziedzicki,  2008;  Smierzchalski  &  Michalewicz,  2000).  The  test  used  a  small  setup,  with 
remote  control  boats,  but  is  not  yet  operational  on  full  size  vessels. 

One  approach  that  has  gone  to  simulator  testing  comes  from  Poland,  and  has  performed 
well  in  aiding  decision  making  by  presenting  safe  trajectories  to  the  CO  as  a  standalone 
tool.  This  system  currently  operates  as  a  simulator,  testing  collision  avoidance  algorithms 
against  poor  hydro  and  meteorological  conditions  (Lebkoswki  et  al.,  2005).  This  is 
important  for  any  operational  system,  as  currents  and  weather  must  always  be  accounted 
for  to  keep  a  ship  on  track.  The  challenge  with  using  any  of  these  algorithms  or 
automation  is  how  best  to  guide  the  commander  of  the  ship  to  make  the  right  decision.  It 
is  important  to  present  information  in  a  display  that  can  quickly  illustrate  the  surrounding 
hazards.  The  next  section  discusses  some  of  the  displays  that  have  come  out  of  current 
research  in  navigation  aids. 
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2.2.3  Navigation  Displays 


From  broad  research  that  focuses  on  the  principles  of  display  design  to  the  specific 
designs  for  collision  avoidance,  there  is  an  abundance  of  research  on  display  design 
(Rasmussen,  1986;  Rasmussen,  Pejtersen,  &  Goodstein,  1994;  Smallman  &  St.  John, 
2005;  Wickens,  Gordon,  &  Liu,  1998).  In  any  interface,  it  is  important  to  present  the 
information  needed  for  decision  making  in  a  logical  and  easily  understandable  fashion 
(Rasmussen,  1986).  To  this  end,  researchers  at  Pennsylvania  State  Applied  Research 
Laboratory  (ARL)  have  developed  a  collision  avoidance  display  that  displays  information 
on  PADs  in  a  unique  way  (Rothgeb,  2008).  This  display  is  shown  in  Figure  5. 


Figure  5:  ARL  Display  with  Multiple  Contacts  (Rothgeb,  2008) 

The  goal  of  the  research  conducted  by  ARL  is  to  develop  a  course  and  contact  advisory 
agent  system  that  provides  threat  awareness,  prioritization,  and  automated 
recommendations  to  maintain  tactical  control  (Rothgeb,  2008).  The  purpose  of  the 
display  is  to  help  reduce  workload  by  reducing  the  time  it  takes  to  make  a  decision,  while 
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improving  the  quality  of  decisions  and  providing  help  for  less  experienced  operators 
(Rothgeb,  2008).  This  is  achieved  by  fusing  data  from  multiple  sensors  to  accommodate 
for  uncertainty  and  form  a  model  representing  the  surrounding  contact  picture.  This 
information  is  then  displayed  in  aggregate  groupings,  showing  yellow,  orange,  or  red 
based  on  the  safety  of  an  area.  Figure  5  shows  a  situation  with  multiple  contacts,  and  how 
the  PAD  is  presented  based  on  where  contacts  would  be  in  the  future. 

The  ARL  display  is  helpful  at  showing  a  general  picture  of  which  areas  are  clear,  and  the 
small  window  on  the  left  provides  a  constant  recommended  trajectory,  but  there  are  still 
some  weaknesses  in  this  display.  For  one,  geographical  information  such  as  land  and 
water  depth  is  not  displayed.  This  can  make  it  difficult  to  maintain  spatial  orientation,  and 
also  requires  operators  to  mentally  integrate  and  synthesize  information  from  multiple 
separate  sources.  Further,  there  is  no  compass  information,  and  tracks  of  future  positions 
are  only  displayed  for  some  of  the  contacts.  This  means  that  the  display  cannot  be  used  as 
a  stand-alone  option,  but  must  be  used  in  addition  to  other  systems.  Introducing  a  new 
display  without  integrating  it  with  other  displays  may  simply  increase  clutter  in  an 
already  overwhelming  environment,  as  discussed  previously.  Another  weakness  of  this 
display  method  is  that  it  only  provides  the  next  course  of  action,  by  presenting  a  direction 
that  is  safe  to  travel  in.  It  does  not  offer  full  routes,  which  makes  long-term  planning 
difficult. 

2.2.4  Decision  Support  for  Health  and  Status  Monitoring 

The  overwhelming  amount  of  information  flowing  to  the  commander  in  the  control  room 
has  led  to  a  difficulty  in  maintaining  SA.  This  was  the  case  with  some  of  the  recent 
submarine  crashes,  most  notably  the  USS  San  Francisco  and  USS  Greeneville.  One  way 
to  aid  commanders  in  this  monitoring  is  to  develop  better  health  and  status  monitoring 
systems,  and  extensive  research  has  been  performed  in  this  area.  A  general  list  of 
requirements  has  been  developed  for  decision  support  systems  by  Guerlain  (2000),  which 
are  directly  relevant  to  health  and  status  monitoring  decision  support  design. 
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The  first  is  interactivity,  the  ability  for  the  system  to  interact  with  the  databases  involved, 
and  also  with  the  user.  Secondly,  it  should  be  simple  to  detect  new  events  or  changes. 
The  system  should  also  aid  the  user  in  representing  the  data,  and  provide  error  detection 
and  recovery.  With  the  vast  amount  of  data  taken  in,  the  system  must  also  have  a  method 
for  turning  the  data  into  useful  information.  Finally,  predictive  capabilities  are  an  added 
benefit,  allowing  users  to  prevent  off-nominal  situations  (Guerlain  et  al.,  2000). 

There  is  a  large  body  of  work  regarding  decision  support  systems  in  process  control 
environments,  where  operators  and  supervisors  must  monitor  large  amounts  of 
information  in  real  time  for  any  unexpected  changes  (Guerlain,  2000;  Guerlain  & 
Bullemer,  1996;  Guerlain  et  al.,  2002).  The  case  of  a  nuclear  submarine  is  not  much 
different  from  other  process  control  activities.  In  both  settings,  a  supervisor  is  needed  to 
monitor  a  set  of  automated  activities,  using  both  current  data  and  predictive  modeling  to 
prevent  hazardous  situations.  Often  times,  the  difficulty  is  not  in  gathering  the  relevant 
data,  but  rather  in  displaying  the  data  in  a  way  that  promotes  the  most  efficient  interface 
with  the  user. 

One  previous  design  project  that  addresses  such  data  fusion  was  the  re-design  of  a  display 
for  a  process  control  model-based  predictive  controller  (MPC)  (Guerlain  et  al.,  2002). 
The  original  display,  used  in  refining,  pulp  and  paper  manufacturing,  and  grinding 
operations  worldwide,  provided  all  the  necessary  information  to  the  user  in  a  manner  that 
was  difficult  to  understand.  Researchers  performed  a  cognitive  task  analysis  to  determine 
what  information  was  needed  for  timely  decision  making.  The  display  was  then  re¬ 
designed,  and  using  the  new  display,  operators  were  able  to  obtain  information  that 
previously  took  much  longer  (Guerlain  et  al.,  2002).  This  research  pointed  to  many  key 
factors  for  display  design.  For  one,  information  should  be  easily  accessible,  without  the 
user  having  to  navigate  between  many  different  screens  and  sub  menus.  Also,  a  system 
that  can  predict  future  states  is  helpful  in  aiding  decision  making.  Trend  displays,  for 
example,  show  values  over  time  that  can  help  the  user  to  predict  future  values  based  on 
the  currently  observed  trend.  Another  lesson  learned  was  that  visual  representation  of 
data  can  help  users  to  quickly  reference  whether  systems  are  functioning  at  an  acceptable 
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level.  There  were  difficulties,  however.  For  one,  complex  systems  often  have  so  many 
different  systems  and  relationships  that  it  is  impossible  to  display  them  all  on  one  screen. 
This  is  why  it  is  important  to  understand  the  domain  in  its  entirety  before  a  new  interface 
is  designed. 

Beyond  simply  creating  an  efficient  display,  further  research  has  shown  the  importance 
of  including  user-initiated  warnings  in  health  and  status  (H&S)  displays  (Guerlain  & 
Bullemer,  1996).  User-initiated  notifications  allow  the  user  to  create  certain  rules  for  the 
automation,  which  will  trigger  alarms  when  set  points  are  violated  (Guerlain  &  Bullemer, 
1996).  Being  able  to  set  custom  warnings  simplifies  the  supervisory  control  task  by 
adding  automation  into  the  monitoring  task.  Rather  than  analyzing  the  gauges, 
automation  can  be  used,  to  a  limited  extent,  to  check  for  trends  that  the  user  defines. 
User- initiated  notifications  prevent  unwanted  warnings,  which  can  be  distracting  to  the 
user  and  further  aids  in  real  time  monitoring  by  limiting  the  delay  between  the  onset  of  a 
dangerous  scenario  and  its  recognition  (Guerlain  &  Bullemer,  1996). 

For  an  effective  health  and  status  monitoring  tool,  it  is  important  to  consider  this  previous 
research.  Creating  a  tool  that  organizes  its  information  into  meaningful  groupings,  and 
aiding  the  user  in  building  their  situational  awareness  is  key.  Using  visual  representations 
and  flagging  key  changes  are  also  important.  Not  only  must  the  tool  meet  the  basic 
requirements  discussed  here  for  representing  data,  but  it  should  also  do  it  in  a  manner  that 
is  intuitive  to  the  user.  With  a  display  that  allows  for  quick  checks  of  the  system  and  the 
ability  to  set  custom  alarm  points,  a  supervisor  can  manage  a  complex  situation  without 
being  overwhelmed. 

2.3  Mobile  Tools  for  Expert  Users 

In  many  different  arenas,  mobile  tools  are  growing  in  popularity.  There  is  a  growing 
desire  to  have  the  flexibility  to  retrieve  information  and  execute  tasks  from  anywhere 
(Perugini,  1996).  As  researchers  from  the  University  of  Nebraska  note,  the  coming 
mobile  revolution  will  bring  dramatic  and  fundamental  changes  to  the  world,  assisting 
decision  makers  in  real  time  (Siau  &  Shen,  2003).  This  can  be  seen  in  the  emergence  and 
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popularity  of  products  such  as  the  iPhone  and  micro  PC’s  that  offer  the  power  to  surf  the 
Internet  and  email  while  still  being  completely  portable. 

The  availability  of  cellular  towers  and  wireless  signals  has  allowed  mobile  technology  to 
grow  at  incredible  rates,  keeping  social  class  and  geography  from  being  limiting  factors 
(Greengard,  2008).  Wireless  capability  enables  real  time  communication,  collaboration, 
and  even  commerce  in  some  cases  (Sarker  &  Wells,  2003).  However,  there  are  some 
limitations  to  mobile  technologies.  One  study  into  mobile  commerce  has  shown  that 
among  the  biggest  constraints  in  mobile  technology  are  slow  CPUs,  limited  processing 
power,  small  screen  size,  low  bandwidth  and  awkward  input/output  devices  (Lee  & 
Benbasat,  2003).  In  terms  of  the  interface,  for  each  mobile  device,  the  actual  display  must 
be  custom  made.  Simply  shrinking  a  desktop  interface  will  not  work  (Lee  &  Benbasat, 
2003).  However,  previous  research  has  shown  that  small  handheld  computers  are 
comparable  to  larger  tablet  PCs  with  respect  to  usability  (Bhattacharjee,  2007). 

One  example  of  a  mobile  technology  that  is  used  to  both  monitor  information  and  execute 
tasks  is  a  stock  trading  tool  designed  by  Wiklund  Research  and  Design  (2005).  This  tool 
allows  expert  users  the  ability  to  trade  stocks  with  the  same  efficiency  as  a  traditional 
desktop  computer,  without  having  to  be  tied  to  a  specific  location.  This  allows  traders  to 
make  quick  decisions,  while  being  presented  with  all  of  the  relevant  information,  and 
beat  competitors  to  the  sale. 

These  mobile  tools  are  seen  in  many  different  arenas.  Another  example,  which  has  also 
gained  popularity,  is  Cogon’s  mobile  device  for  medical  decision  support.  This  device 
aids  medical  personnel  in  quickly  gaining  information  on  a  patient  and  works  seamlessly 
with  the  existing  database  to  prevent  redundant  entries  (Cogon  Systems,  2007).  Mobile 
tools  are  also  found  in  the  command  and  control  domain.  Because  these  tools  can  lead  to 
life  or  death  decision  making,  they  must  be  much  more  robust  in  terms  of  error  recovery 
and  ease  of  use.  The  Commander,  a  tool  designed  by  The  Resource  Group,  is  one 
example  of  a  command  and  control  tool  (McEwan,  2009).  This  tool  allows  for  mobile 
control  of  a  UAV  by  an  operator  in  the  field.  This  tool  is  more  than  just  a  portable  control 
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for  basic  functions;  it  provides  advanced  control  operations  for  the  user  without  size 
limitations 

Because  the  operating  environment  of  today’s  soldier  is  often  removed  from  the  office, 
mobile  technology  allows  increased  capability  in  field  settings.  One  example  is  the 
handheld  lie  detector,  developed  by  Lafayette  Instrument  Company  (Dedman,  2008). 
This  tool  allows  troops  in  the  field  to  do  basic  questioning  of  non-U. S.  personnel  to  aid  in 
determining  credibility  at  access  points,  as  well  as  in  gaining  information  following  an 
attack  (Dedman,  2008).  Other  examples  of  mobile  military  technology  include  handheld 
translators,  mine  detection  systems,  and  several  mobile  PCs  for  commanders  (Doheny, 
2007;  Krane,  2002). 

One  tool  that  reportedly  supports  ground-based  commanders  is  called  a  Commanders 
Digital  Assistant,  first  deployed  in  2003  (Kempin,  2004).  The  purpose  of  this  tool  is  to 
provide  situational  awareness  capability  to  dismounted  leaders  by  providing  information 
on  maps  and  troop  location  similar  to  what  can  be  gained  in  a  command  and  control 
station  (Kempin,  2004).  The  tool  also  has  the  ability  to  aid  in  planning,  and  provides  a 
map  of  the  battle  space,  listing  the  location  of  known  friendly  forces.  This  information 
keeps  commanders  in  the  loop,  without  constraining  them  to  the  command  center  the  way 
previous  tools  did.  Thus,  it  embodies  many  of  the  same  principles  that  apply  to 
commanders  of  submarines.  The  main  strength  for  many  of  these  mobile  technologies  is 
that  they  free  the  supervisor  from  being  constrained  to  a  desk,  while  still  giving  access  to 
needed  critical  information. 

This  review  of  previous  literature  has  shown  that  there  are  clear  benefits  of  mobile 
technology,  collision  avoidance  systems,  and  well-designed  health  and  status  monitoring 
decision  support  systems.  However,  there  is  no  decision  support  tool  that  incorporates 
these  three  characteristics  in  maritime  settings.  To  fill  this  gap,  this  research  effort 
proposes  the  use  of  a  mobile  command  assistant,  the  Mobile  Situational  Awareness  Tool 
(MS AT),  to  aid  in  surface  collision  avoidance  and  platform  health  and  status  monitoring, 
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embodied  in  a  mobile  device.  The  following  chapters  discuss  the  design,  testing,  and 
performance  of  the  MSAT  in  more  detail. 
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3.  Design  of  the  Mobile  Situational  Awareness  Tool 

3.1  Introduction 

A  common  technique  used  to  analyze  a  domain  in  order  to  derive  interface  design 
concepts  and  requirements  is  a  cognitive  task  analysis  (CTA)  (Schraagen,  Chipman,  & 
Shalin,  2000).  A  CTA  can  involve  a  number  of  different  methods,  but  the  end  goal  is  to 
learn  more  about  a  task  by  determining  the  cognitive  processing  involved.  This  includes 
mapping  the  decisions  and  processes,  as  well  as  gaining  an  understanding  of  the  priorities 
and  rules  followed  for  a  task.  With  a  better  understanding  of  the  tasks  and  decisions 
involved,  research  can  be  focused  on  addressing  shortcomings. 

For  this  research,  two  different  types  of  CTAs  were  performed.  The  first  was  a  traditional 
CTA,  which  consisted  of  interviews  with  SMEs  and  a  five-day  cruise  on  the  USS  New 
Hampshire,  a  Virginia  Class  submarine.  The  second  was  a  Hybrid  CTA  (HCTA).  One 
limitation  of  traditional  CTA  processes  is  that  they  rely  heavily  on  the  existence  of  a 
predecessor  system,  which  is  problematic  when  designing  for  future  systems  that  require 
some  form  of  automated  decision  support.  The  HCTA  was  developed  to  address  this 
shortcoming  of  traditional  CTAs  (Nehme  et  al.,  2006),  as  this  project  involves  the 
application  of  automated  path  planners  in  a  mobile  device,  which  is  a  revolutionary 
technology  for  the  submarine  forces. 

The  HCTA  explicitly  provides  functional  and  informational  requirements  for  futuristic 
systems  by  stepping  analysts  through  a  requirements-generation  process,  with  an 
embedded  analysis  of  tasks  that  may  be  appropriate  for  higher  levels  of  automation.  Each 
step  in  the  HCTA  is  based  on  a  structured  methodology  to  make  it  repeatable  and 
traceable,  and  it  can  be  used  when  subject  matter  experts  (SME)  are  not  available.  The 
outputs  from  the  HCTA  are  functional  requirements  and  lower  level  information 
requirements  needed  to  support  these  functions  and  include  SA  requirements,  display 
requirements,  and  areas  for  possible  automation. 
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The  traditional  CTA,  conducted  for  overall  submarine  operations  focused  on  the  health 
and  status  monitoring  functions.  Across  the  submarine,  there  are  many  systems  that 
require  constant  monitoring.  Interviews  with  submarine  officers  provided  insight  into 
what  systems  are  monitored,  how  long  tasks  take,  and  where  time  is  wasted.  The  HCTA 
focused  on  developing  requirements  for  a  decision  support  for  the  specific  tasks  of 
surface  navigation  and  collision  avoidance,  which  are  frequently  performed  tasks  and 
central  to  all  submarine  missions.  The  results  from  both  CTAs  are  presented  in  the  next 
sections. 

3.2  Traditional  CTA  results 

From  the  onset  of  this  research,  many  submarine  officers  were  interviewed  about  the 
submarine  environment,  navigation,  and  possible  shortcomings.  These  interviews  were 
conducted  at  shore-based  facilities,  as  well  as  during  a  five-day  cruise  on  the  USS  New 
Hampshire,  where  operations  were  observed  in  person.  In  addition  to  loosely  structured 
interview  questions,  a  subset  of  ten  highly  experienced  submarine  officers  were  given  a 
set  of  written  questions  to  gather  information  on  different  tasks.  Only  officers  were  used 
because  the  interest  was  in  supporting  health  and  status  monitoring  for  officers.  These 
questions  formed  the  basis  of  a  time  and  motion  study,  and  are  discussed  in  further  detail 
in  Chapter  4.  These  question  and  answer  sessions  provided  a  great  deal  of  information  on 
current  submarine  operations,  and  some  of  the  highlights  are  discussed  here. 

One  of  the  first  trends  that  surfaced  during  interviews  was  the  fact  that  submarine 
designers  often  do  not  understand  submarine  life.  For  example,  some  personnel 
referenced  valve  placements  that  were  dangerous,  because  the  crew  has  to  reach  between 
hot  pipes  in  order  to  make  adjustments.  Some  of  the  officers  that  worked  in  the  control 
room  also  stressed  the  difficulty  with  staying  informed  once  out  of  the  control  room. 
Only  basic  information  on  submarine  heading,  course,  and  depth  can  be  seen  in  other 
areas,  and  so  it  becomes  difficult  to  maintain  situational  awareness.  Other  comments 
dealt  with  the  difficulty  of  maintaining  a  regular  sleep  schedule,  as  the  lighting  and 
shared  living  spaces  make  it  difficult  for  peace  and  quiet.  This  is  further  complicated  by 
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the  18-hour  workdays.  Once  the  crew  is  underway,  everyone  works  a  twelve-hour  shift, 
and  then  has  six  hours  off. 

Many  of  the  officers  who  just  recently  returned  from  sea  mentioned  the  new  AIS  system. 
As  mentioned  in  Chapter  2,  this  system  tracks  the  information  of  all  commercial  vessels 
using  it,  broadcasting  the  ship  name,  position,  course,  speed  and  destination.  This 
information  can  simplify  the  tracking  process,  but  the  officers  said  that  it  was  added  on  as 
an  afterthought,  and  does  not  connect  well  with  the  other  systems  already  in  place.  These 
comments  proved  true  during  the  five  day  cruise.  The  AIS  display  was  tucked  in  a  corner 
above  one  of  the  operator’s  normal  display.  The  information  was  rarely  used  as  a  primary 
source,  and  only  a  few  times  was  it  used  to  check  information  gained  from  one  of  the 
other  sensors.  Since  AIS  provides  accurate  course  and  speed  information  provided  from 
the  actual  ship  in  question,  it  seems  unreasonable  to  not  use  this  information  as  the 
starting  point  for  building  up  the  contact  picture. 

Other  new  systems  have  also  found  their  way  into  the  control  room,  but  are  also  not 
integrated  in  any  permanent  manner.  The  commercial  radar,  for  example,  must  be  hand 
carried  to  the  bridge  every  time  the  vessel  surfaces  and  be  manually  mounted  to  the  deck, 
which  takes  two  crew  members  approximately  30  minutes.  The  bridge  is  the  tall  part  of 
the  submarine,  which  rises  above  the  water,  and  is  where  lookouts  stand  while  navigating 
on  the  surface.  During  the  times  when  the  submarine  was  on  the  surface,  it  was  clear  that 
the  stress  level  for  all  personnel  was  much  higher,  with  many  more  people  in  the  control 
room  and  an  additional  set  of  lookouts  on  the  bridge.  During  such  a  busy  time,  the  task  of 
setting  up  an  additional  radar  dish  is  overly  burdensome. 

In  current  submarine  operations,  the  transition  from  paper  to  electronic  charts  has  been 
slow.  Until  the  Virginia  class,  electronic  charts  such  as  those  in  the  Voyage  Management 
System  were  not  allowed  as  a  primary  means  of  navigation.  Although  the  paper  charts 
have  their  benefits,  there  are  still  disadvantages  to  plotting  courses  by  hand.  The  process 
is  very  tedious,  requiring  various  tools  and  a  large  amount  of  space.  This  difficulty  was 
observed  during  a  charting  demonstration  by  a  Navy  submariner.  If  re-planning  is 
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necessary,  plotting  a  new  path  by  hand  can  become  time  intensive,  as  it  is  difficult  to 
compare  the  options  available  in  a  timely  fashion.  Also,  as  each  successive  path  is  plotted 
and  erased  from  a  chart,  the  picture  becomes  faded  and  worn  from  use,  and  the  chart  can 
become  difficult  to  read.  Many  of  the  officers  interviewed  saw  the  potential  benefits  of 
the  VMS,  but  acceptance  was  not  unanimous. 

The  addition  of  the  VMS  has  helped  to  pool  information,  but  when  underway,  many 
complaints  were  also  raised.  Although  the  VMS  works  towards  combining  and 
condensing  information,  there  are  still  limitations.  First,  the  VMS  is  still  not  technically 
very  reliable.  During  the  five-day  cruise,  the  VMS  froze  multiple  times,  requiring  it  to  be 
restarted  each  time.  This  delayed  information  flow  and  causing  a  break  in  mission 
execution  in  the  control  room.  Also,  the  information  coming  from  the  VMS  is  only 
helpful  to  those  who  are  within  sight  of  it.  It  is  hard  to  get  the  necessary  information  to  a 
commander  who  is  anywhere  but  in  the  control  room.  Thus,  if  the  VMS  information  were 
placed  on  a  mobile  device,  this  would  greatly  aid  in  the  flow  of  information. 

Another  finding  from  the  interviews  and  the  short  cruise  was  that  the  number  of  systems 
onboard  the  submarine  that  must  be  continuously  monitored  is  vast.  From  engine 
parameters  and  temperatures  to  atmospheric  levels,  weapons  positions,  and  sensor 
strength,  there  are  many  things  that  the  commander  must  constantly  watch.  The  typical 
process  involves  delegating  these  monitoring  tasks  to  someone  else,  and  only  being 
notified  in  an  off-nominal  scenario.  This  can  be  problematic,  as  the  information  is  very 
disjointed,  and  is  logged  in  many  different  areas  with  no  easy  way  to  keep  track.  These 
shortcomings  are  what  inspired  the  need  for  a  health  and  status  monitoring  function  of  the 
MSAT.  Giving  the  commander  constant  access  to  these  key  system  parameters  can  aid  in 
safety  as  well  as  helping  to  keep  the  commander  in  the  loop. 

The  information  gained  from  these  interviews  helped  to  frame  current  problems  in  terms 
of  information  the  commanding  officer  needs  to  know.  The  Hybrid  CTA,  discussed  in  the 
next  section,  focused  on  the  specific  areas  that  could  benefit  from  automation,  and  the 
associated  information  requirements. 
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3.3  Hybrid  Cognitive  Task  Analysis 

The  Hybrid  CTA  approach  consists  of  the  following  components:  1)  Generating  a 
scenario  task  overview,  2)  Generating  an  event  flow  diagram,  3)  Generating  situational 
awareness  requirements,  and  lastly,  4)  Creating  decision  ladders  for  critical  decisions 
from  which  information  and  display  requirements  are  extracted.  An  outline  of  these  steps 
can  be  seen  in  Figure  6  (Nehme,  et.  al.,  2006).  Each  of  these  steps  is  described  in  more 
detail  below  as  they  relate  to  the  development  of  a  display  for  collision  avoidance. 


Decision 
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Situation  awareness 
requirements 
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Display  requirements 


Information 
and  function 
requirements 


Figure  6:  Hybrid  Cognitive  Task  Analysis  Process  (Nehme  et  al.,  2006) 

In  order  to  complete  the  HCTA  analysis,  some  assumptions  were  made.  In  order  to  keep 
it  task  specific,  it  was  assumed  that  the  submarine  had  to  stay  at  the  surface  during 
navigation.  This  is  a  realistic  need  since  communication  becomes  very  difficult  for  a 
submerged  submarine,  making  surface  transit  a  common  choice,  particularly  in  congested 
environments  (Clancy,  1993).  The  analysis  focuses  on  supporting  a  single  decision  maker 
monitoring  the  surface  navigation  picture  (like  a  submarine  commander).  There  are  no  a 
priori  assumptions  about  crew  size,  and  indeed,  one  possible  application  of  the  HCTA 
would  be  using  the  results  to  aid  in  estimating  an  overall  manning  model.  The  results  of 
both  CTAs  are  discussed  in  further  detail  below. 
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3.3.1  Generating  a  Scenario  Task  Overview 


The  Hybrid  CTA  begins  with  a  scenario  description  of  the  overall  mission.  From  there, 
the  overall  mission  is  divided  into  several  phases,  the  boundaries  of  which  are  identified 
by  the  changes  in  expected  operator  tasking,  both  in  time  and  sub-task  groupings.  For 
each  phase,  the  sub-goals  of  that  phase  are  enumerated,  and  the  expected  subtasks  for 
each  of  these  sub-goals  are  detailed.  Further  subdivisions  can  take  place,  resulting  in  a 
hierarchy,  branching  from  the  mission  statement,  to  an  individual  subtask  at  the  leaf 
level.  The  scenario  task  overview  allows  for  later  stage  modification  or  revision  of  a 
phase  goal  or  sub-task.  A  subset  can  be  seen  in  Figure  7. 


Phase  Goals 

Phase  Breakdown 

Exit  Harbor 

-  Cast  off  from  docking  position 

-  Orient  craft  to  exit  path 

-  Check  for  contacts  in  area 

-  Follow  navigational  aides  to  exit  harbor  while  following 
rules  of  the  road 

-  Determine  whether  to  stall  or  change  direction  if  path  is 
blocked 

-  Determine  whether  to  change  path  or  wait  for  tides  to  change 
if  depth  is  an  issue 

-  Exit  harbor  phase  is  complete  when  the  craft  is  outside  the 
confines  of  the  docking  area 

Mission 

Execution 

Terrain 

Confined 

Navigation 

-  Set  up  possible  course 

-  Determine  potential  obstructions  both  under  and  above  water 

-  Determine  whether  stopping  or  slowing  is  better  based  on 
currents  and  navigation  ability,  if  traffic  is  heavy 

-  Determine  from  the  mission  time  constraint  whether  there  is 
any  ability  to  slow  down  passage 

-  Determine  what  contacts  may  cause  interference  based  on 
realistic  path  prediction  based  on  past  experience 

-  Determine  limitations  on  contact  maneuverability 

-  Determine  possible  paths  for  burdened  vessel  to  compare 
with  actual  path 

-  Phase  completed  when  avoiding  contact  with  terrain  is  no 
longer  the  primary  concern 

Figure  7:  Partial  Scenario  Task  Overview 


Based  on  the  given  scenario  of  surface  collision  avoidance  during  navigation,  the 
nominal  tasks  were  grouped  into  four  main  phases:  Exit  Harbor,  Restricted  Water 
Navigation,  Unrestricted  Water  Navigation,  and  Return  to  Port.  These  phases  cover 
surface  collision  avoidance  in  all  areas,  each  of  which  contains  its  own  unique 
challenges.  From  these  phases,  a  list  of  all  the  possible  subtasks  was  developed  through 
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research  and  interviews  with  current  submarine  crew  members,  while  focusing  on  the 
tasks  of  surface  navigation.  The  entire  list  of  tasks  expected  for  each  of  the  four  phases  is 
listed  in  Appendix  A. 

3.3.2  Generating  the  Event  Flow  Diagram 

The  next  step  of  the  HCTA  involves  generating  event  flow  diagrams  for  each  phase. 
While  the  scenario  task  overview  determines  what  tasks  and  subtasks  are  needed  to 
execute  the  mission,  the  event  flow  diagram  demonstrates  the  temporal  constraints,  i.e., 
when  the  events  must  occur  in  relation  to  each  other.  There  are  two  basic  event  types 
used  in  the  event  flow  diagram: 

o  Decisions,  which  could  be  simple  decisions  (yes/no)  or  could  be  ones  that  require 
knowledge-based  input  from  the  operator,  represented  by  diamonds,  and 
o  Processes  that  require  human-computer  interaction  to  support  a  mission  subtask, 
represented  by  rectangles. 


Figure  8:  Partial  Event  Flow  Diagram  for  the  Exit  Harbor  Task 


The  first  event  flow  diagram  covers  the  Exit  Harbor  phase  (Appendix  Bl).  A  portion  can 
be  seen  in  Figure  8.  This  phase  starts  as  the  vessel  casts  off  and  ends  when  the  vessel  is 
outside  the  bounds  of  the  harbor.  Some  of  the  key  subtasks  in  this  phase  are  determining 
areas  that  are  open  to  travel,  identifying  contacts  in  the  area,  and  observing  the  tide  and 
currents.  This  event  flow  covers  the  different  decisions  an  operator  may  face,  such  as 
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whether  to  delay  movement  or  change  path,  as  well  as  processes  such  as  determining  the 
right  of  way  with  any  surrounding  contacts. 

The  next  event  flow  diagram  represents  Restricted  Water  Navigation  (Appendix  B2). 
With  the  exception  of  entering  and  exiting  port,  this  phase  represents  any  navigation 
where  avoiding  terrain  is  a  factor.  This  phase  increases  in  complexity  when  contacts  are 
in  the  area,  especially  when  collision  is  possible.  This  event  flow  also  represents  the  need 
to  account  for  structural  limits  of  the  craft  and  variances  in  the  paths  of  surrounding 
contacts. 

The  Unrestricted  Water  Navigation  event  flow  represents  any  navigation  in  open  water 
where  terrain  avoidance  is  not  an  issue  (Appendix  B3).  The  important  tasks  here  include 
locating  any  surrounding  contacts  and  mapping  their  paths.  Collisions  must  be  avoided 
through  obeying  the  rules  of  the  road,  which  dictate  who  has  the  right  of  way  in  different 
navigation  scenarios.  Any  craft  not  displaying  Automatic  Identification  System  (AIS) 
data  must  also  be  tracked  in  order  to  prevent  collisions.  This  phase  ends  when  the 
ownship  craft  enters  any  area  where  terrain  becomes  an  obstacle. 

The  final  stage,  Return  to  Port,  starts  when  the  harbor  pilot  is  picked  up  and  ends  when 
the  craft  is  safely  docked  (Appendix  B4).  The  harbor  pilot  is  a  person  who  is  familiar 
with  the  specific  area  and  its  navigation  rules,  and  is  used  whenever  a  submarine  enters  a 
port  to  aid  in  navigation.  The  event  flow  represents  the  series  of  events  that  must  occur 
before  transiting  to  port,  such  as  securing  systems  and  determining  the  status  of  tides  and 
currents.  It  also  allows  for  tug  boat  assistance,  depending  on  whether  tugs  are  available 
and  whether  their  help  would  make  the  port  accessible  when  external  factors  prevent 
normal  transit.  The  tasks  listed  in  these  event  flow  diagrams  show  the  key  processes  and 
decisions  made  during  navigation,  and  are  used  to  generate  the  SA  requirements  and 
decision  ladders. 
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3.3.3  Generating  SA  Requirements 


Situation  awareness  is  a  critical  aspect  of  human  supervisory  control,  particularly  time- 
sensitive  command  and  control  operations.  In  order  to  account  for  this,  the  third  step  of 
the  HCTA  involves  the  generation  of  SA  requirements  for  each  of  the  mission  phases  and 
associated  subtasks  identified  in  the  first  two  steps.  Because  SA,  by  definition,  is 
inherently  linked  to  temporal  constraints,  the  SA  requirements  cannot  be  generated  until 
the  event  flow  diagram  is  constructed.  The  SA  requirements  generated  in  this  step  are 
divided  into  the  three  SA  levels,  perception,  comprehension,  and  projection  (Endsley, 
1995).  For  each  SA  level,  situational  awareness  requirements  are  specified  for  the 
mission  phases  and  associated  subtasks  derived  in  the  scenario  task  overview,  keeping  in 
mind  the  temporal  constraints  of  the  event  flow  diagrams. 

In  Level  1  SA,  perception  of  information,  is  essentially  obtaining  the  correct  mental 
picture  of  the  situation.  Level  2  SA,  comprehension,  is  the  integration  of  multiple  pieces 
of  information  and  a  determination  of  their  relevance  to  the  mission  goals. 
Comprehension  also  means  deriving  operationally  relevant  meaning  and  significance 
from  the  Level  1  SA  data.  Level  3  SA,  Projection,  requires  operators  to  forecast  the 
future  situation  events  and  dynamics.  Operators  who  have  this  ability  can  anticipate 
future  events  by  projecting  from  current  events,  allowing  for  timely  and  accurate 
decision-making.  Figure  9  shows  a  segment  of  the  SA  requirements  for  the  Exit  Harbor 
Phase. 

Each  SA  requirement  for  the  task  of  navigation  is  linked  to  a  decision  and/or  process  to 
which  it  relates,  allowing  traceability  from  each  output  to  its  source.  The  requirements 
are  also  grouped  by  phases,  as  some  phases  have  different  needs  in  order  to  complete 
tasks.  SA  requirements  such  as  contacts  positions,  geo-spatial  boundaries,  and  contact 
paths  are  seen  multiple  times,  as  this  information  is  needed  in  many  phases.  Most  of  the 
Level  1  requirements  are  necessary  to  inform  the  operator  of  his  or  her  surroundings. 
Displays  that  meet  Level  3  requirements  give  operators  a  deeper  understanding  of  what  is 
going  on  around  them,  promoting  the  ability  to  forecast  the  outcome  of  their  decisions. 
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The  complete  list  of  SA  requirements  for  the  task  of  collision  avoidance  is  in  Appendix 
C. 


Figure  9:  Partial  Situational  Awareness  Requirements 


3.3.4  Generating  Decision  ladders 

Each  decision  in  the  event  flow  diagram  represents  a  critical  event  that  requires  detailed 
understanding  of  what  information  and  knowledge  is  needed  to  support  the  operator’s 
decision-making  process.  By  generating  decision  ladders,  the  states  of  knowledge  and 
information-processing  activities  necessary  to  reach  a  decision  can  be  captured 
(Rasmussen,  1983). 


In  a  decision  ladder,  human  behavior  is  represented  using  a  three  level  hierarchy.  The 
first  and  lowest  level  is  skill-based  behavior,  generally  characterized  by  volitional 
sensory  motor  acts,  where  performance  takes  place  without  conscious  control.  At  the 
middle  level  is  the  rule-based  behavior.  This  level  works  on  stored  rules,  which  are 
selected  from  previous  learning  in  similar  circumstances.  The  third  and  top-most  level  is 
knowledge-based  behavior.  In  this  level,  behavioral  responses  of  individuals  are  based  on 
the  analysis  of  cues  within  the  environment  and  also  on  the  goals  of  the  particular 
individual  (Rasmussen,  1983).  Figure  10  shows  the  three  levels  of  the  hierarchy. 
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Knowledge-based  domain 


Skill-based  domain 

Figure  10:  Decision  Ladder  with  its  Hierarchy  (Rasmussen,  1983) 


As  illustrated  in  Figure  10,  the  decision  ladder  depicts  relationships  among  the  levels  of 
causal  reasoning  (human  behavior)  and  states  of  knowledge.  The  figure  has  two  different 
shapes:  boxes  and  circles.  Boxes  illustrate  the  information  processing  activities  involved 
in  each  decision  phase,  and  circles  represent  the  information  or  knowledge  produced, 
which  feeds  into  the  next  decision  phase.  In  general,  after  observing  the  data  from  the 
environment,  the  evaluation  and  interpretation  of  the  data  becomes  possible  and 
accordingly,  an  action  is  executed  (Rasmussen  et  al.,  1994). 

In  the  HCTA,  the  complex  decisions  embedded  in  the  scenario  phases  are  explained  in 
detail  with  the  help  of  a  decision  ladder.  Complex  decisions  are  those  characterized  by 
many  variables  with  often  dynamic  constraints,  as  well  as  significant  uncertainty  in  the 
environment.  A  scenario  can  have  multiple  complex  decisions  embedded  in  it,  and  each 
of  these  decisions  is  depicted  with  a  decision  ladder.  A  feature  of  the  HCTA  process  is 
that  each  decision  ladder  includes  overlaid  display  requirements. 
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In  generating  decision  ladders,  the  various  steps  are  as  follows: 

Develop  a  traditional  decision  ladder  for  each  critical,  complex  decision 

Construct  two  variations  of  each  decision  ladder 

o  In  one,  the  corresponding  display  requirements  are  added, 
o  In  the  other,  the  possible  levels  of  automation  are  added. 

Decision  ladders  were  completed  for  each  of  the  critical  decisions  found  in  the  event  flow 
diagrams,  and  can  be  seen  in  Appendix  D.  The  four  critical  decisions  are: 

1.  “Is  desired  course  accessible?” 

2.  “Would  tug  boat  assistance  make  course  possible?” 

3.  “Are  there  any  contacts  in  the  area?” 

4.  “Is  collision  possible?” 

The  goal  of  the  first  decision,  determining  if  the  course  is  accessible,  is  to  see  if  there  are 
any  external  factors  preventing  navigation,  such  as  tides,  current,  weather,  etc.  This  is  a 
complex  decision  due  to  the  diverse  set  of  problems  that  can  arise.  Also,  the  question  of 
whether  the  course  is  accessible  does  not  always  have  a  binary  answer,  as  different 
obstacles  are  not  necessarily  static.  For  example,  a  land  mass  is  impassable,  but  if  the 
obstruction  is  another  vessel,  simply  waiting  may  clear  the  path.  Observations  from 
available  sensors  help  determine  how  obstacles  affect  the  path,  and  the  decision  ends 
when  the  status  of  the  path  has  been  determined  as  either  passable  or  blocked.  This 
decision  ladder  can  be  seen  in  Appendix  Dl. 

The  second  is  a  follow-on  decision  to  determine  if  using  tug  boats  is  an  option  when  the 
desired  path  appears  to  be  inaccessible,  for  example,  in  the  presence  of  a  strong  tide.  The 
complexity  of  this  decision  prevents  a  simple  answer,  as  there  are  many  factors  that  must 
be  taken  into  account.  First,  information  about  the  external  conditions  is  needed,  followed 
by  an  evaluation  of  whether  the  tug  boat  capabilities  can  overcome  the  problem.  Once  the 
path  is  finalized,  and  depending  on  whether  tug  boats  will  be  used,  the  necessary  steps 
are  taken  in  order  to  continue  with  navigation.  This  decision  process  is  in  Appendix  D2. 
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The  third  decision  ladder,  looking  for  contacts,  is  entered  whenever  the  ownship  craft 
moves  into  an  area  with  unknown  possible  contacts.  Since  various  sensors  are  used  in 
order  to  determine  what  contacts  are  in  the  area,  the  resulting  information  is  complex, 
with  different  levels  of  reliability.  This  makes  the  decision  complex,  with  multiple  steps. 
Again,  sensor  data  are  taken  in  and  analyzed  to  determine  what  is  in  the  surrounding  area. 
This  information  is  then  used  to  update  the  display  with  the  surrounding  contacts,  along 
with  their  predicted  paths.  If  there  are  no  possible  contacts,  the  craft  continues  navigating 
and  monitoring  until  new  information  is  received.  The  full  decision  ladder  is  in  Appendix 
D3. 

The  final  decision  deals  with  navigation  when  contacts  have  been  discovered  in  the  area, 
raising  the  possibility  of  a  collision.  This  occurs  when  a  contact  has  been  detected  in  or 
near  the  operating  area.  Since  the  course  of  each  ship  is  constantly  changing  due  to  tides, 
currents,  and  traffic  patterns,  this  is  a  complex  decision.  The  contact’s  current  course  and 
relative  speed  must  be  known  (or  at  least  estimated),  and  then  the  likelihood  of  collision 
is  determined  based  on  the  current  paths  and  possible  variations.  If  a  collision  is  possible, 
the  rules  of  the  road  are  applied,  and  a  new  course  should  be  planned,  if  necessary.  This 
decision  ladder  is  shown  in  Appendix  D4. 

Once  completed,  each  step  in  the  decision  ladder  is  then  assessed  to  determine  what 
display  information  is  required  to  support  the  actions  and  knowledge-based  reasoning,  as 
well  as  identify  what  processes  could  be  automated.  The  display  requirements,  as  seen  in 
Figure  11  and  Appendix  D,  are  contained  in  the  shaded  callout  boxes.  The  display 
requirements  do  not  assert  a  specific  “how”  in  terms  of  information  needed  for  a  decision 
but  only  “what”.  It  is  left  to  the  designer  to  determine  which  mode  (i.e.,  visual,  aural,  or 
haptic)  in  which  to  present  this  information,  as  well  as  how  to  combine  it  with  other 
relevant  data,  etc.  The  specific  design  of  the  MSAT,  guided  by  these  requirements,  is 
discussed  in  more  detail  in  section  3.4. 
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Figure  11:  Partial  Display  Requirements 

Finally,  the  levels  of  possible  automation  are  added  to  the  decision  ladders  in  order  to 
show  which  steps  are  possible  candidates  for  automation,  with  the  ultimate  goal  of 
reducing  mental  workload  of  the  operator.  Each  action  block  on  a  decision  ladder  is 
assessed  to  determine  if  it  is  an  action  that  can  be  done  with  some  level  of  automation, 
and  if  so,  it  is  marked  as  a  candidate  for  automation.  One  example  is  in  the  decision  of 
changing  the  path  when  the  craft  is  on  a  collision  course.  One  of  the  steps  requires  re¬ 
planning  the  path  to  avoid  a  conflict,  given  the  rules  of  the  road.  Because  this  task  is  rule 
based,  and  can  be  completed  without  knowledge  level  decision  making  of  a  human, 
automation  may  be  able  to  help.  This  is  an  area  where  automation  can  be  applied  through 
a  tool  such  as  an  automatic  path  planner. 

Figure  12  shows  how  automation  can  decrease  operator  workload  by  removing  one  of  the 
steps  in  the  decision  making  process.  With  computer  assistance,  all  of  the  obstacles  and 
possible  paths  can  be  checked  against  each  other,  and  a  possible  solution  can  be 
presented  to  the  operator.  This  reduces  the  mental  workload  on  the  operator,  which  can 
lead  to  decreased  manning  and  more  efficient  collision  avoidance.  Automation 
possibilities  for  all  the  ladders  are  shown  in  Appendix  D,  depicted  in  the  callout  boxes. 
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Figure  12:  Partial  Possible  Automation  Diagram 


3.3.5  Information  and  Functional  Requirements 

Fifty-two  information  requirements  were  defined  for  the  function  of  collision  avoidance, 
broadly  categorized  in  geo-spatial  information,  contact  information,  alerts  and  feedback, 
and  data/miscellaneous  groupings.  These  requirements  are  shown  in  Appendix  E.  Each 
requirement  can  be  traced  back  to  either  the  SA  requirements  and/or  the  display 
requirements,  as  indicated  in  the  requirements  list. 


3.4  Specific  Display  Requirements  for  Design  of  a  Decision  Support  Tool 

Of  the  submarine  functions  listed  in  Chapter  2,  a  subset  was  chosen  for  illustration  in  the 
MS  AT,  highlighted  in  Figure  13.  Because  of  the  path  planning  automation,  a  special 
focus  was  put  on  navigation  in  the  littoral  regions,  where  contact  and  obstacle  presence  is 
highly  likely.  With  this  in  mind,  representative  functions  were  chosen  to  demonstrate 
how  such  a  mobile  tool  would  integrate  the  information,  as  well  as  due  to  their  critical, 
central  role  (i.e.,  navigation,  collision  avoidance,  and  health  and  status  monitoring 
represent  the  most  common  tasks  aboard  a  submarine).  Also,  these  tasks  represent 
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continuous  activities  for  the  commander  to  follow,  and  the  tasks  are  broad  enough  to 
keep  the  results  generalizable  to  other  maritime  settings. 


Figure  13:  Submarine  Function  Focus 


3.5  Mobile  Situational  Awareness  Tool 

The  next  paragraphs  describe  the  resultant  display  that  was  designed,  given  the 
previously  discussed  requirements.  Throughout  the  design  process,  guiding  principles 
were  followed  to  ensure  that  the  information  presented  was  shown  in  a  clear  fashion.  One 
set  of  principles  used  were  Jakob  Neilsen’s  heuristics  (Nielsen,  1994).  Some  of  the  more 
notable  items  are  giving  the  user  control  and  freedom,  having  a  match  between  the 
system  and  the  real  world,  being  able  to  simply  recover  from  errors,  and  following 
standards  (Nielsen,  1994).  These  design  principles  are  important,  because  following  them 
will  lead  to  a  simple  system,  from  the  user’s  perspective,  and  also  easier  to  leam.  Other 
general  principles  were  followed  with  regards  to  basic  visual  perception,  such  as  keeping 
similar  buttons  together,  and  having  the  interactions  represent  real  world  movements 
(Ware,  2000).  The  design  is  discussed  is  more  detail  in  the  following  sections,  keeping 
these  principles  in  mind. 

Due  to  the  large  amount  of  information  that  must  be  monitored,  as  well  as  the  functional 
grouping  of  the  different  information  types,  the  display  was  developed  with  different 
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tabs.  With  the  limited  screen  space  on  a  mobile  tool,  a  tabbed  display  allows  for 
increased  information  without  overwhelming  a  single  display.  Based  on  the  requirements, 
three  natural  groups  of  information  emerged.  The  first  is  general  information  viewed 
most  often.  The  second  group  under  the  Navigation  tab  provides  all  the  information  for 
navigation  and  path  planning.  A  third  grouping  include  all  of  the  health  and  status 
monitoring  information,  and  finally  a  fourth  option  is  included  to  show  how  such  a  tool 
could  be  extended  to  include  additional  functionality  such  as  a  3D  visual  environment  for 
increased  SA.  The  information  is  broken  down  into  the  following  four  tabs:  Overview, 
Navigation,  Health  and  Status  and  Rite  View,  and  the  sections  below  discuss  how  these 
tabs  meet  the  display  requirements  identified  through  HCTA.  The  complete  User’s 
Manual  for  the  display  can  be  found  in  Appendix  F. 

3.5.1  Overview  Tab 

The  first  tab  in  Figure  14  is  the  Overview  tab.  For  most  commanders,  there  is  a  constant 
need  to  see  the  geospatial  representation  of  the  surroundings,  the  obstacles,  and  basic 
information  such  as  course,  speed,  and  depth.  As  a  default,  this  information  was  grouped 
together  into  the  Overview  tab,  which  also  contains  contact  management  information  for 
the  closest  point  of  approach  (CPA)  of  each  surrounding  contact.  For  some  users,  this 
may  not  be  the  primary  display,  but  it  was  placed  in  the  primary  position  because  it 
covers  general  overarching  information  required  by  a  submarine  commander.  This  tab 
gives  basic  navigation  information  and  helps  to  build  the  picture  of  the  surroundings  and 
current  path,  as  can  be  seen  in  Figure  14. 

This  interface  provides  various  pieces  of  information  to  support  the  commander.  The  map 
portion  in  Figure  14  shows  the  current  position  (blue  U  shape)  (1),  current  path  (black 
line)  (2)  with  waypoints  (triangles)  (3),  and  a  hazard  that  has  shown  up  on  the  map  (red 
area)  (4).  The  colors  were  selected  to  match  what  is  used  in  conventional  paper  charts, 
and  the  hazards  are  shown  in  red  to  draw  the  user’s  attention.  Contacts  are  shown  as  light 
blue  circles  (5),  with  numbers  on  the  circle,  and  a  vector  showing  their  movement 
direction.  This  matches  the  military  standard  for  friendly  contacts  (U.S.  Department  of 
Defense,  1999).  The  goal  position  is  shown  in  yellow  (6). 
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Figure  14:  Overview  Tab 

At  the  bottom  of  Figure  14,  the  depth  track  along  the  course  is  shown  (7),  including  the 
entire  course  and  waypoints,  with  the  distance  between  the  top  and  the  plotted  line 
representing  the  depth.  This  helps  the  user  to  see  a  profile  view  of  the  depth  along  the 
course,  something  that  is  not  typically  available  on  charts.  A  second  line  (8)  shows  the 
user- specified  minimum  depth  requirement.  This  can  be  changed  using  the  navigation 
tab. 

On  the  right  side,  the  compass  shows  the  current  heading  of  the  ship  (9),  indicated  by 
both  the  red  arrow  and  the  digital  readout  in  the  center.  Both  methods  are  used  for 
redundancy,  and  also  to  give  quick  information  through  the  pictorial  display  as  well  as 
the  specific  heading  for  navigation  purposes.  To  the  right  of  the  compass  is  the 
speedometer,  which  is  dual-coded  with  shading  and  a  digital  readout  in  the  center  (10). 
Below  these  are  updated  latitude  and  longitude  coordinates  (11)  (which,  while  not  critical 
for  SA,  are  a  feature  insisted  upon  by  users),  as  well  as  the  current  depth  and  the 
minimum  depth  along  the  path  (12).  Finally,  a  table  of  contact  information  is  shown  at 
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the  bottom  right  corner  (13).  This  table  can  be  sorted  by  contact  number,  CPA,  or  time  to 
CPA  by  clicking  on  the  column  heading. 

Many  of  the  geospatial  requirements  from  Appendix  E  are  met  in  this  tab,  such  as 
providing  a  map,  current  location,  and  the  position  of  surrounding  obstacles.  Information 
on  contacts,  including  their  closest  point  of  approach  (CPA)  is  given  in  the  bottom  right, 
and  the  information  can  be  sorted  by  contact  number,  CPA  distance,  or  CPA  time  by 
clicking  on  the  columns.  Also,  the  chart  on  the  bottom  shows  the  current  position  of  the 
submarine  and  the  depth  track  from  the  current  location  to  the  goal.  The  map  shows  the 
position  of  ownship,  as  well  as  contact  positions  and  headings. 

3.5.2  Navigation  Tab 

The  navigation  tab  contains  the  information  needed  for  the  task  of  navigation  and 
collision  avoidance.  This  view  is  shown  in  Figure  15. 
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Figure  15:  Navigation  Tab 


Contact  location,  current  position,  goal,  and  different  path  options  are  displayed  on  this 
tab.  This  information  is  presented  on  a  separate  tab  from  the  overview  information 
because  it  allows  for  changes  to  the  current  path,  and  so  more  space  is  needed  for  the 
planning  tools.  The  map  area  is  also  displayed  in  lighter  colors  to  prevent  mode 
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confusion  with  the  Overview  tab  and  prevent  users  from  accidentally  changing  the  path 
(Wickens  &  Hollands,  2000).  The  navigation  tab  is  designed  to  aid  the  commander  in 
quick  decision  making  by  giving  assistance  during  path  planning.  From  this  tab,  the 
current  path  can  be  modified,  updated,  or  changed  completely  using  either  a  manual  or 
automation-based  method  called  Autoplan. 


When  using  the  Autoplan  feature,  the  automation  determines  this  path  using  an  A* 
Algorithm,  which  is  a  heuristic  search  algorithm  that  looks  for  the  best  path  by 
optimizing  the  constraints  set  by  the  user.  This  algorithm  takes  into  account  the  minimum 
depth,  visibility  and  separation  level,  and  finds  the  shortest  path  from  the  current  location 
to  the  goal  that  meets  all  of  these  requirements  (Buchin,  2009).  Figure  16  shows  a  sample 
output  for  the  Autoplan  paths. 
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Figure  16:  Automated  Paths 


As  shown  in  Figure  16,  there  are  three  different  automation  paths  presented.  These  paths 
represent  different  levels  of  risk  the  CO  is  willing  to  take.  As  the  automation  predicts 
where  a  contact  will  be  in  the  future,  the  three  paths  account  for  different  levels  of 
uncertainty  in  each  contact’s  path.  The  low  separation  path  is  used  when  there  is  low 
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uncertainty  in  a  contact’s  path,  which  means  the  path  is  much  closer  to  the  contact.  For 
high  uncertainty,  a  much  more  risk  adverse  path  is  developed,  leaving  more  room 
between  the  submarine  and  any  contacts.  This  functionality  was  built  into  the  system  to 
allow  users  to  choose  a  path  based  on  the  level  of  risk  they  find  acceptable.  For  example, 
if  most  of  the  contacts  were  sailboats,  which  are  less  predictable,  a  high  separation  path 
would  be  safer.  However,  if  most  of  the  contacts  were  merchant  vessels,  which  follow 
very  fixed  courses  and  speeds,  then  a  low  separation  path  could  be  a  more  efficient  way 
to  reach  the  goal. 

Figure  17  shows  an  expanded  view  of  the  navigation  tab.  Along  the  bottom  of  this  tab, 
proposed  paths  can  be  compared  by  distance  and  time  (1)  (these  will  be  described  in 
more  detail  below).  On  the  right,  checking  the  corresponding  boxes  (1)  can  change  the 
view  of  different  paths,  created  either  by  the  human  or  the  automation.  The  L,  M  and  H 
Separation  section  represents  the  low,  medium  and  high  separation  paths  made  by  the 
automation.  Low  separation  paths  allow  for  movements  closer  to  the  contacts,  and  high 
separation  paths  leave  more  space  between  ownship  and  contacts.  If  the  Autoplan  button 
is  used,  all  of  the  L,  M,  and  H  paths  are  created,  and  then  the  user  can  compare  them  with 
the  graphs  and  the  navigation  map  to  choose  the  one  that  best  fits  his  or  her  needs. 
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Below  the  checkboxes  are  the  three  different  inputs  for  the  automation,  each  with  a  slider 
bar.  These  slider  bars  are  shown  on  the  right,  denoted  as  (a),  (b)  and  (c).  The  first  is 
minimum  separation  from  obstacles  (a).  This  user-generated  setting  means  that  all 
proposed  paths  will  have  at  least  this  amount  of  distance  between  ownship  and  any 
surrounding  contacts  or  shoal  water.  Next  is  the  minimum  depth  setting  (b)  and  minimum 
visibility  setting  (c),  which  also  must  be  set  by  the  user.  These  sliders  were  designed  to 
show  both  relative  position  and  a  digital  readout,  so  that  the  user  can  quickly  plan  a  path 
or  be  more  specific  with  inputs.  For  depth  and  visibility,  the  cutoff  point  can  also  be 
compared  across  the  current  path,  to  filter  out  undesirable  paths  through  a  simple 
movement  of  the  slider.  Only  paths  that  meet  these  requirements  will  be  considered  by 
the  automation.  The  two  graphs  show  a  comparison  of  depth  and  visibility  by  the  paths 
that  are  created  (3).  The  view  in  Figure  16  shows  only  the  current  path,  but  manual  and 
automation  paths  are  added  to  the  view  as  they  are  created.  Thus,  a  maximum  of  six  paths 
can  be  shown  at  the  same  time  (the  current,  one  proposed  manual,  and  four  proposed 
Autoplan  routes).  Finally,  the  controls  at  the  bottom  right  are  used  to  create  these  manual 
or  computer- generated  paths. 

Once  the  path  is  developed,  it  can  be  modified  by  either  moving,  adding  or  deleting 
waypoints.  When  performing  any  of  these  path  planning  tasks,  the  underlying  automation 
prevents  the  user  from  violating  any  of  the  pre-set  conditions.  For  example,  paths  cannot 
be  plotted  through  land,  and  warnings  will  display  in  the  manual  mode  if  users  create  a 
path  that  violates  the  input  depth,  visibility,  or  separation  distance.  The  system  also  warns 
users  before  a  path  is  deleted,  to  prevent  accidental  loss  of  information.  Before  changes  to 
the  current  path  can  be  finalized,  a  final  confirmation  box  appears,  ensuring  that  the  user 
is  ready  to  update  the  current  course.  When  any  changes  are  made,  the  graphs  on  the  right 
update  automatically  to  show  depth  and  visibility  along  the  track. 

3.5.3  Health  and  Status  Tab 

The  Health  and  Status  (H&S)  tab  provides  information  on  many  systems  across  the  ship. 
For  submarine  commanders,  health  and  status  monitoring  is  an  important  task  during  all 
operations,  whether  on  the  surface  or  submerged.  With  so  many  different  functions  on  the 
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submarine,  it  is  a  constant  burden  for  the  commander  to  monitor  subsystems  such  as  air, 
weapons  position,  and  sensor  strength.  The  health  and  status  display  runs  parallel  to  the 
operational  missions,  ensuring  that  everything  is  working  properly.  Since  one  of  the  key 
components  of  this  research  is  determining  how  to  assist  a  submarine  commander  in 
surface  operations,  the  health  and  status  tab  was  added  as  one  of  the  necessary  outputs 
because  of  the  direct  benefits  that  come  from  knowing  the  status  of  systems  across  the 
submarine.  For  the  purposes  of  this  research,  the  systems  that  were  the  most  difficult  to 
monitor  were  chosen  to  be  represented  in  this  display. 

There  were  many  considerations  in  designing  the  H&S  tab.  One  problem  seen  on  the 
Virginia  class  submarines  is  with  the  alarm  systems.  The  various  stations  in  the  control 
room  are  set  up  to  monitor  everything  from  possible  collisions,  shallow  water,  low  air 
pressure,  reactor  problems,  and  more.  All  of  these  alarms  go  to  different  stations  with 
different  people  monitoring  each.  Critical  alarms  are  passed  on  to  the  commander  when 
realized  by  the  primary  monitors  of  all  different  subsystems,  over  7  in  all.  If  the  person 
monitoring  a  system  does  not  think  an  alarm  is  critical,  that  information  flow  stops,  and 
the  commander  is  not  informed.  It  is  important  to  prevent  commander  information 
overload,  but  critical  alarms  can  be  dropped  before  reaching  the  commander,  as  well  as 
not  communicated  to  other  members.  This  communication  problem  with  alarm  states  can 
be  addressed  with  a  more  robust  H&S  system  that  automatically  provides  some  of  these 
alerts  to  the  commander. 

Other  alarm  systems  are  poorly  designed.  The  high-pressure  air,  for  example,  has  a  set 
point  that  once  reached,  causes  the  alarm  to  sound.  In  order  to  prevent  this  from 
happening,  commanders  typically  assign  someone  to  monitor  the  system  and  set  an 
artificial  alarm  at  a  higher  value.  This  wastes  resources  and  is  potentially  dangerous.  One 
way  to  address  this  workaround  is  through  user-initiated  notifications,  which  allow  the 
user  to  set  an  artificial  alarm  at  a  higher  or  lower  value.  This  can  be  in  the  form  of  a 
simple  warning  rather  than  a  full-blown  alarm,  and  can  still  keep  the  commander  in  the 
loop.  The  MSAT  H&S  tab  acts  as  a  funnel  for  many  of  these  alarms.  This  way,  the  most 
important  alarms  would  go  directly  to  the  commander,  and  other  alarms  can  be  set  to 
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desired  points  based  on  the  commander’s  risk  for  various  alerts,  warnings,  and  alarms. 
The  first  view  for  the  H&S  tab  gives  high-level  information  across  many  systems,  based 
on  what  the  CO  might  be  most  interested  in  viewing.  This  information  is  presented 
similar  to  its  placement  on  the  actual  submarine  to  aid  in  quick  searches  for  information, 
and  help  with  pictorial  realism  (Figure  18). 
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Figure  18:  Health  and  Status  Tab 


This  view  uses  a  standard  color  scheme,  where  red  is  danger,  yellow  is  caution,  and  green 
is  acceptable.  Also,  for  the  rudder  angle  (Rud.  Ang.),  red  and  green  are  used  to  match  the 
port  and  starboard  (P  and  S)  lights,  conventional  for  maritime  lighting  schemes.  From 
this  view,  the  user  can  change  the  warning  levels  for  different  atmospheric  levels  by 
moving  the  yellow  line  to  a  new  set  point  (1).  The  red  line  represents  the  fixed  warning 
level  that  is  built  into  the  system.  These  user-initiated  notifications  serve  many  purposes. 
First,  they  give  control  to  the  user,  helping  to  build  trust  in  the  system.  Next,  they  provide 
added  flexibility  on  warnings,  as  the  commander  can  set  the  warnings  so  that  he  can  be 
notified  long  before  a  critical  situation  is  reached.  They  also  allow  the  warnings  to  be 
personalized  for  each  user. 
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The  user  can  also  gain  more  specific  system  information  by  clicking  the  buttons  on  top. 
For  example,  if  the  Air  button  is  clicked,  the  display  changes  to  show  a  detailed  picture  of 
the  atmospheric  levels  over  time.  For  weapons,  the  detailed  position  of  each  weapon  on 
the  rack  is  shown,  as  well  as  what  is  currently  in  each  tube.  From  the  basic  view  above, 
the  user  can  see  that  three  of  the  four  torpedo  tubes  are  full,  but  there  is  no  indication  here 
of  what  is  in  those  tubes  (2).  The  full  H&S  range  of  displays  is  shown  in  Appendix  G. 

3.5.4  Rite  View  Tab 

The  final  tab  is  the  Rite  View  tab.  This  tab  uses  a  3-D  simulation  environment  currently 
in  development  by  Rite- Solutions,  Inc,  and  is  seen  in  Figure  19. 


This  tab  helps  to  meet  many  of  the  situational  awareness  requirements,  by  providing  an 
exocentric  view  of  the  surroundings.  One  of  the  problems  with  highly  realistic  displays  is 
the  assumption  that  people  can  accurately  extract  information  from  these  3-D  interfaces 
(Smallman  &  St.  John,  2005).  People  often  perform  worse  with  a  3-D  display  for  tasks 
involving  finite  measurements  (Smallman  &  St.  John,  2005).  So  while  3-D  environments 
are  not  the  best  for  making  specific  course  adjustments,  they  do  provide  a  simple 
visualization  to  aid  in  overall  situational  awareness.  This  environment  has  the  ability  to 
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show  and  hide  many  different  layers  of  information,  which  can  be  used  to  assist  the 
commander  in  determining  his  geospatial  location  and  surroundings.  Also,  it  provides  a 
quick  overview  at  the  surrounding  contacts  and  hazards  that  may  affect  future  navigation. 
The  supporting  overview  and  navigation  tab  can  provide  the  more  specific  information 
for  making  exact  judgments,  while  the  Rite  View  tab  gives  the  overall  picture.  Thus  the 
navigation  and  Rite  View  tabs  are  complementary 

3.6  Flexibility 

The  MSAT  was  designed  to  allow  flexibility  in  the  information  displayed.  Using  the  tabs, 
new  information  can  be  added,  or  current  information  can  be  removed,  allowing  the  tool 
to  be  customized  for  each  user  or  mission  type.  By  customizing  the  display,  other 
members  of  the  submarine  could  make  use  of  the  MSAT,  such  as  the  executive  officer 
(XO),  navigator,  or  any  other  member  that  desires  updated  information  on  a  mobile 
device.  Displays  such  as  dive  controls  and  checklists  can  also  be  included,  along  with  any 
existing  display  across  the  submarine.  In  the  reverse,  MSAT  views  could  be  put  on  a 
larger  display  in  the  control  room  for  quick  checks  among  the  crew.  Beyond  the 
submarine,  this  same  device  can  also  aid  surface  ships,  both  civilian  and  military. 
Because  the  MSAT  was  designed  based  on  many  of  the  tasks  that  occur  in  other 
commercial  and  military  vessels,  the  results  are  generalizable  to  other  maritime  vessels  as 
well. 

3.7  Summary 

The  overall  design  of  the  MSAT  provides  a  unique  interface  that  brings  together 
information  from  across  the  submarine  and  presents  it  to  the  user  in  a  simple  interface, 
meant  to  be  highly  intuitive.  This  display  also  provides  a  flexible  interface  that  can 
benefit  other  surface  operations.  By  designing  the  interface  based  on  a  formal,  principled 
set  of  requirements,  the  process  ensures  that  all  of  the  key  information  needed  for 
decision  making  is  available  to  the  user.  A  final  list  of  the  requirements  met  in  the  MSAT 
is  shown  in  Table  1,  listing  the  original  requirement  as  well  as  the  display  tab  where  the 
requirement  is  met. 
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Table  1:  Fulfilled  Requirements 


Requirement  Description 

Display  location(s) 

Geo-spatial  boundaries 

Overview,  Navigation, 

Rite -View 

Hazardous/restricted  areas 

Overview,  Navigation, 

Rite-View 

Tide,  current,  weather,  marked  on  display 

Navigation 

Planned  course,  highlighted  red  if  blocked,  green  if  clear 

Overview,  Navigation 

Visual  indication  of  allowable  paths  when  helpful 

Navigation 

Mark  final  destination  or  goal  location  on  map 

Ability  to  determine  range  from  ownship  to  other  points  of 
interest 

Overview,  Navigation 
Navigation 

Geo-spatial  location  of  all  surrounding  contacts 

Overview,  Navigation, 

Rite-View 

Contacts  course  and  speed 

Overview 

Specific  sensor  data  available  for  review 

Health  and  Status 

Highlight  sensor  data  that  most  likely  represents  a  contact 

Overview,  Navigation 

Contact  path:  past,  present  and  future 

Overview,  Rite-View 

Contact  location  on  path 

List  of  contacts,  with  name,  bearing,  speed,  and  whether  course  is 
opening/closing 

Overview,  Navigation, 
Overview 

Rite-View 

When  craft  is  on  a  collision  course  with  a  contact 

Navigation 

When  planned  course  violates  limits  or  set  restrictions 

Navigation 

Current  speed  and  heading 

Overview 

Ability  to  compare  different  routes 

Navigation 
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4.  MSAT  Evaluation 


4.1  Introduction 

After  any  design  process  comes  to  completion,  it  is  important  to  use  sound  testing 
methods  to  rate  the  quality  of  the  tool  developed.  The  MSAT  was  designed  around  the 
problem  of  improving  decision-makers’  situation  awareness,  focusing  on  both  presenting 
high-level  health  and  status  of  systems,  while  also  being  able  to  assist  in  the  various 
functions  carried  out  by  submarine  commanders.  In  order  to  test  the  tool  against  the 
objectives  laid  out  in  Chapter  1,  two  separate  methods  were  employed.  The  first  was  a 
time  and  motion  study,  which  used  interviews  with  SMEs  to  determine  how  the  MSAT 
compares  with  current  monitoring  methods.  The  second  was  a  navigation  experiment, 
which  was  performed  to  determine  how  well  users  can  interact  with  automated  planning 
tools.  The  navigation  experiment  also  provided  a  platform  to  test  users  to  determine  their 
trust  in  a  mobile  automated  planning  tool.  The  following  sections  describe  these  methods 
in  more  detail. 

4.2  Time  and  Motion  Study 

The  first  test  performed  was  the  time  and  motion  study.  A  time  and  motion  study  is  used 
to  study  a  method  or  process  to  determine  how  the  process  can  be  simplified  or  improved 
(Robbins  et  al.,  2003).  Although  the  process  can  vary  in  its  specifics,  there  are  general 
steps  followed  in  each  case.  First,  the  process  itself  is  chosen,  in  this  case  the  monitoring 
of  a  nuclear  submarine.  Next,  all  the  relevant  data  is  collected  for  the  process.  Following 
this,  the  process  can  be  evaluated  to  determine  where  efficiency  is  lacking,  or  where 
improvements  can  be  made.  After  determining  the  shortcomings  in  the  current  methods, 
new  methods  can  be  developed  to  fix  these  problems. 

The  interviews  discussed  in  the  CTA  chapter  formed  the  basis  of  the  time  and  motion 
study.  During  these  interviews,  ten  submarine  officers  from  different  classes  of  Navy 
submarines  were  questioned  to  determine  trends  in  task  time,  and  see  how  often  tasks 
were  performed.  These  results  were  then  compared  with  the  MSAT,  by  estimating  how 
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long  it  would  take  to  perform  the  same  task  using  the  handheld  tool.  These  results  will  be 
discussed  in  the  next  chapter. 

4.3  Navigation  Experiment 

The  second  test  performed  was  a  navigation  experiment.  The  goal  of  this  test  was  to 
evaluate  how  the  MSAT  performs  as  a  navigation  aid  when  compared  with  current  paper 
and  pencil  methods.  Since  the  navigation  tab  also  allows  for  user  interaction,  the  test  also 
provided  insight  as  to  how  easy  the  display  was  to  use  for  complex  tasks. 

4.3.1  Experimental  Design 

For  this  experiment,  participants  were  tested  with  two  navigation  scenarios,  one  using  a 
paper  chart  and  one  using  the  MSAT.  Two  different  counterbalanced  scenarios  were  used 
to  control  for  learning  effects.  Users  from  both  military  and  civilian  maritime 
backgrounds  were  recruited  to  assess  trends  in  trust  and  performance  based  on  training 
and  job  experience.  A  2x2  mixed  factorial  design  was  used  with  user  experience  (military 
or  civilian)  as  a  between-subject  variable  and  decision  support  (MSAT  or  Paper  chart)  as 
a  within-subjects  variable.  Each  user  performed  the  experiment  using  the  same  map,  and 
used  one  tool  to  navigate  from  top  to  bottom,  and  the  other  tool  to  navigate  from  left  to 
right. 

Results  were  compared  by  both  path  length  and  the  time  it  took  to  complete  planning. 
The  path  length  was  measured  as  the  total  distance  between  the  start  position  and  yellow 
goal  position  (see  Figure  15),  which  was  measured  automatically  on  the  MSAT  and  by 
hand  using  paper  charts.  A  stopwatch  was  used  for  all  the  subjects  to  record  how  long  it 
took  from  the  time  planning  was  started  until  the  path  reached  the  goal  position.  After 
completing  the  path,  a  questionnaire  was  administered  to  gauge  users’  trust  levels. 

4.3.2  Participants 

Eight  military  personnel  from  both  Coast  Guard  and  Navy,  and  eight  civilians  from  the 
MIT  sailing  pavilion  and  the  Massachusetts  Maritime  Institute  with  experience  in 
navigating  in  open  waters  were  recruited.  The  average  age  of  the  military  personal  was 
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31  years  old,  with  a  standard  deviation  of  7  years,  and  a  range  of  23-47  years.  The 
average  age  of  the  civilians  was  41  years  old,  with  a  standard  deviation  of  10  years,  and  a 
range  of  27-59  years.  Only  male  participants  were  employed  in  the  experiment  since  the 
submarine  community  is  only  composed  of  men. 

4.3.3  Apparatus 

For  this  experiment,  two  different  sets  of  tools  were  used.  The  first  was  the  MSAT,  which 
runs  based  on  a  Java  executable  file.  This  file  was  run  on  a  Sony  Vaio  Micro  PC,  model 
number  UX390N,  with  a  1024x600  screen  resolution.  The  second  set  of  tools  used  was 
for  the  paper  and  pencil  navigation  task.  Each  participant  was  given  a  map  and  a  printout 
of  the  expected  visibility  (a  representative  weather  map),  using  the  same  values  as  those 
used  by  the  MSAT.  Each  participant  was  also  given  a  set  of  navigation  tools,  including  a 
compass,  ruler,  parallel  plotter,  rolling  ruler,  pencil,  and  eraser,  with  which  they  were  all 
familiar.  Each  participant  plotted  their  path  on  tracing  paper  used  by  the  Navy,  which  was 
covering  the  map.  Times  were  recorded  using  a  stopwatch,  and  distances  were  measured 
using  a  standard  ruler  and  converted  to  nautical  miles  using  the  same  scale  as  the  MSAT. 

4.3.4  Procedure 

All  participants  were  first  given  a  practice  scenario  with  both  the  paper  tools  and  the 
MSAT.  These  scenarios  were  set  up  exactly  like  the  actual  test  scenarios,  with  the 
exception  of  the  map  used.  For  the  practice  scenario,  a  different  map  was  used  to  prevent 
learning  effects  with  route  planning.  For  the  experimental  scenarios,  participants  were 
randomly  assigned  to  one  of  four  combinations  of  scenario  and  navigational  tool 
groupings  listed  below. 

•  MSAT  left  to  right  navigation  followed  by  paper  top  to  bottom  navigation 

•  MSAT  top  to  bottom  navigation  followed  by  paper  left  to  right  navigation 

•  Paper  left  to  right  navigation  followed  by  MSAT  top  to  bottom  navigation 

•  Paper  top  to  bottom  navigation  followed  by  MSAT  left  to  right  navigation 
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The  same  map  was  used  in  all  scenarios,  with  the  left  to  right  navigation  moving  across 
the  screen  from  the  top  left  to  the  top  right,  and  the  top  to  bottom  navigation  moving  from 
the  top  center  to  bottom  center.  Participants  completed  the  task  using  either  the  MSAT, 
with  time  starting  once  the  system  was  given  to  the  participant,  and  ending  once  a  new 
path  was  created  and  chosen,  or  with  paper  and  pencil,  with  time  stopping  once  the 
participant  reached  the  goal.  Following  the  experiment,  a  trust  questionnaire  was 
administered  (Appendix  I).  The  complete  experimental  protocol  for  the  navigation 
experiment  can  be  found  in  the  thesis  by  Buchin  (2009). 

4.3.5  Dependent  Variables 

Table  2  shows  the  performance  dependent  variables. 


Table  2:  Performance  Dependent  Variables 


Metric 

Interpretation 

Path  length 

Length  from  start  to  goal,  converted  to  nautical  miles  for 
consistency  between  paper  and  MSAT  map  and  normalized 
based  on  the  absolute  shortest  path 

Obstacle  avoidance 

Avoiding  collisions  with  other  obstacles,  including  both  land 
and  other  contacts  (a  binary  yes/no  value) 

Time  to  generate  path 

Time  from  when  the  obstacle  was  presented  to  when  the  new 
path  was  submitted 

Trust  variables 

Trust,  accurateness,  reliability,  usability,  and  robustness  were 
all  assessed  using  a  post  experiment  questionnaire 

4.4  Summary 

The  design  of  the  MSAT  is  based  on  addressing  the  shortcomings  seen  in  previous 
systems.  In  order  to  evaluate  the  MSAT  to  ensure  that  it  is,  in  fact,  an  improvement,  two 
tests  were  performed.  The  first  test  measured  the  MSAT’s  ability  to  perform  health  and 
status  monitoring  functions.  By  performing  a  time  and  motion  study,  the  possible  time 
savings  that  can  be  gained  through  using  the  MSAT  were  determined.  To  address  the 
benefits  of  using  the  MSAT  for  navigation,  a  second  experiment  was  performed.  The 
goal  was  to  determine,  based  on  task  time  and  task  efficiency,  whether  the  MSAT  is  a 
better  tool  for  navigation.  The  results  of  these  tests  are  discussed  in  Chapter  5. 
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5.  Results  and  Discussion 


5.1  Time  and  Motion  Study  Results 

After  the  time  and  motion  study  questions  were  asked  to  a  field  of  ten  submarine  officers, 
the  results  were  recorded  for  evaluation  (questions  in  Appendix  H).  The  responses  for 
each  task  time  were  then  compared  with  an  estimate  of  how  long  the  same  task  would 
take  with  the  MSAT.  Due  to  the  limited  pool  of  submarine  officers  with  different 
operational  experience,  there  was  large  variability  in  the  responses.  The  estimates  for  the 
MSAT  were  single  point  estimates,  since  they  are  based  on  users  locating  and  selecting 
the  correct  data,  which  has  little  variability  for  expert  users.  The  MSAT  estimates  were 
determined  based  on  the  time  needed  to  both  cognitively  process  a  task,  and  then  to  carry 
out  the  task  using  the  MSAT.  The  results  for  the  time  and  motion  study  are  broken  down 
into  the  following  three  categories:  physical  movement,  navigation,  and  health  and  status 
monitoring. 
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Figure  20:  Movement  Time  Survey  Responses  for  Physical  Movement 

The  survey  results  in  Figure  20  show  the  average  response  time  and  variability  for  the 
first  two  questions.  The  first  set  of  questions  was  a  simple  comparison  of  the  two  main 
trips  carried  out  by  a  submarine  commander.  The  first  is  moving  from  the  stateroom  to 
the  control  room.  The  stateroom  is  the  living  quarters  of  the  CO,  and  so  movement 
between  the  two  locations  occurs  often  by  the  CO  so  he  can  seek  out  information  and 
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keep  a  high  level  of  situational  awareness.  Movement  from  the  bridge  to  the  torpedo 
room  represents  another  movement  the  CO  might  need  to  make.  Since  the  MSAT 
presents  information  without  requiring  movement  into  the  control  room  or  torpedo  room, 
the  graph  represents  time  that  can  be  saved  using  the  MSAT. 

Because  the  MSAT  would  allow  commanders  to  obtain  the  information  needed  from  the 
control  room  or  weapons  room  without  having  to  be  physically  present,  there  is  no  need 
to  make  these  trips  anymore.  Currently,  the  commander  needs  to  move  from  his 
stateroom  to  the  control  room  to  get  information,  but  with  the  MSAT,  this  information  is 
available  wherever  the  commander  is.  Since  these  movements  are  no  longer  necessary  to 
gain  information,  the  time  to  gain  this  information  is  simply  the  time  it  takes  to  click 
through  to  the  navigation  tab.  These  time  savings  would  occur  every  time  the  commander 
would  have  previously  moved.  Throughout  a  typical  day,  these  time  savings  could  add  up 
to  be  a  much  more  significant  amount  of  time. 
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Figure  21:  Navigation  Time  Responses 


The  second  set  of  questions  dealt  with  time  saved  for  the  task  of  navigation.  There  are 
many  processes  involved  in  navigation,  and  the  tasks  used  for  the  time  and  motion  study 
are  shown  in  Figure  21.  The  questions  ranged  from  simply  gathering  AIS  data  to  more 
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difficult  tasks  such  as  plotting  an  entire  new  path.  The  responses  for  each  of  these  tasks 
using  the  current  methods  are  compared  to  the  MS  AT  estimates  in  Figure  21. 

The  range  in  Figure  21  shows  a  great  deal  of  variability  for  these  responses,  likely  due  to 
the  personal  experiences  of  each  submariner.  Comparing  the  average  time  with  the 
MSAT  estimates  shows  the  large  potential  savings.  This  is  because  plotting  a  new  path 
takes  a  significant  amount  of  time  using  conventional  methods,  due  to  the  large  amount 
of  information  needed  and  the  difficulty  in  plotting  each  leg.  With  the  MSAT,  which 
takes  in  this  information  automatically,  a  new  path  can  be  plotted  in  seconds  using  the 
Autoplan  feature. 

The  final  grouping  of  questions  addressed  health  and  status  monitoring.  These  questions 
dealt  with  the  checks  and  measurements  performed  by  the  commander  to  ensure  that  the 
overall  submarine  is  functioning  within  normal  limits.  The  responses  for  the  time  it  takes 
currently  to  perform  these  tasks  are  shown  in  Figure  22,  along  with  the  MSAT  estimates. 
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Figure  22:  Health  and  Status  Survey  Responses 


The  average  time  savings  given  the  MSAT  are  clear.  The  MSAT  has  the  ability  to  track 
many  of  the  submarine’s  systems  in  real  time,  which  would  prevent  waiting  for  rounds  to 


71 


be  made,  and  also  give  the  information  in  its  entirety  in  one  central  display.  However,  not 
all  tasks  here  show  large  savings.  Some  of  the  monitoring  tasks,  such  as  checking  the 
engine/rudder  positions  and  torpedo  tubes,  are  currently  performed  in  an  effective 
manner,  and  so  the  MSAT  simply  matches  this  value  rather  than  improving  it.  The 
MSAT  excels  with  the  more  complex  tasks,  such  as  monitoring  air  levels  due  to  the  aid 
of  automation. 

The  MSAT  affects  many  roles,  as  it  shifts  work  previously  done  by  the  crew  over  to  the 
automation.  Many  of  the  monitoring  tasks,  such  as  checking  gauges  for  air  levels,  can  be 
done  automatically  by  a  computer,  and  that  information  can  go  directly  to  the  MSAT. 
Since  many  of  these  time  savings  are  relatively  small,  it  may  be  difficult  to  simply  cut 
manning.  Instead,  re-allocation  of  resources  can  help  to  improve  workflow  by  changing 
roles  and  responsibilities.  A  shift  in  roles  can  allow  for  more  evenly  distributed  work,  or 
even  just  more  sleep,  while  also  giving  the  commander  more  rapid  access  to  information. 
Beyond  simply  reducing  task  time,  the  variability  of  tasks  can  also  decrease. 

Using  the  MSAT  to  decrease  time  on  task  can  be  related  to  a  cut  in  costs.  Based  strictly 
on  the  cost  of  various  crew  involved,  and  an  estimate  of  how  many  times  per  day  a  task  is 
performed,  an  estimate  was  made  for  the  total  cost  savings.  This  estimate  takes  into 
account  who  is  involved  in  each  task,  what  the  pay  rate  is  for  each  of  these  members,  and 
how  many  times  the  task  is  performed  each  day.  An  example  would  be  plotting  a  new 
path.  Not  only  must  the  commander  dictate  a  new  path,  but  the  navigator  and  plotter  must 
also  work  to  create  the  actual  path.  The  time  taken  by  the  navigator  and  plotter  can  be 
converted  to  a  cost  using  the  formula  shown  in  Equation  1. 

Money  Saved  =  Time  Saved  *  Pay  ( dollars )  (1) 

Task  Task  Time 

This  equation  uses  the  average  time  saved  per  task  based  on  the  survey  results,  and  the 
pay  is  based  on  current  submarine  pay  scales  including  allowances.  Since  some  tasks 
require  multiple  people  of  different  ranks,  these  tasks  are  handled  separately,  and  a  cost  is 
calculated  based  on  the  time  each  task  takes  to  perform.  These  time  savings  for  each  task 
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are  the  amount  of  time  that  would  be  saved  using  the  MSAT  versus  current  methods,  and 
Table  3  shows  a  summary  of  the  time  saved  for  many  of  the  common  tasks  performed 
during  daily  operations. 

Table  3:  Time  Savings 


Task 

Average 

Time  (sec) 

Frequency 

Time  saved 

MSAT 

Current 

/day 

/day  (sec) 

Movement  Tasks 

Stateroom  to  control  room 

1 

19.8 

6 

118.7 

Bridge  to  torpedo  room 

1 

72.2 

4 

288.9 

Navigation  Tasks 

Input  AIS  Data 

1 

158.0 

50 

7850.0 

Notify  CO  of  problem  on  path 

1 

55.0 

10 

540.0 

Sort  contacts  by  CPA 

2 

65.9 

40 

2554.3 

Change  one  waypoint 

3 

50.0 

10 

470.0 

Check  parameters  of  path 

2 

347.1 

4 

1380.6 

Plot  a  new  path 

10 

3365.0 

1 

3355.0 

Monitoring  Tasks 

Engine/rudder 

2 

15.8 

75 

1033.3 

Atmospheric  levels 

2 

1234.3 

24 

29574.9 

Munitions  position 

3 

480.0 

4 

1908.0 

Contents  of  torpedo  tubes 

3 

50.0 

4 

188.0 

Status  check  for  submerging 

3 

1955.7 

2 

3905.4 

Status  check  for  GPS 

2 

930.0 

4 

3712.0 

Sonar  Range 

3 

306.0 

4 

1212.0 

Based  on  the  time  savings  shown  in  this  chart,  the  average  time  saved  in  a  typical  day 
that  could  be  gained  from  using  the  MSAT  is  over  16  hours.  This  is  across  the  whole 
crew,  but  on  a  mission  that  lasts  over  six  months,  this  can  add  up  quickly.  Similarly,  if 
broken  down  by  cost  based  on  pay  rates,  the  money  saved  during  a  six-month  mission  is 
nearly  $35,000  dollars  (Defense  Finance  and  Accounting  Service,  2009).  This  amount  is 
based  on  a  members  pay  (including  average  housing  and  food  benefits)  broken  down  by 
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time,  assuming  a  40-hour  workweek1.  While  not  a  drastic  savings,  it  shows  that  there  is 
room  for  improvement  in  the  current  methods  of  carrying  out  these  tasks,  and  that  new 
methods  can  aid  in  increasing  efficiency  through  better  resource  allocation  or  changes  in 
manning.  The  MSAT  is  not  a  fully  functional  tool,  but  the  methods  used  can  lead  to 
improved  operations. 

Table  4:  Comparison  of  Means  for  Different  Tasks 


Task  (Parametric  t  tests) 

Mean  Difference 

t-value 

p-value 

Move  from  stateroom  to  control  room 

19.8 

3.16 

.01* 

Move  from  bridge  to  torpedo  room 

72.2 

5.44 

.00* 

Gather  AIS  data 

157.0 

1.88 

.13 

Plot  new  path 

3668.0 

1.63 

.18 

Check  atmospheric  levels 

1232.3 

2.09 

.08 

Determine  weapon  position  on  rack 

477.0 

1.14 

.46 

Check  contents  of  firing  tubes 

47.0 

4.70 

.04* 

Check  status  for  submerging 

1952.7 

3.52 

.01* 

Check  status  of  GPS 

928.0 

1.07 

.48 

Task  (Non-Parametric  Responses) 

Notify  commander  of  problem  on  path 

54.0 

— 

.00* 

Sort  contacts  by  CPA 

63.9 

— 

.13 

Change  one  waypoint 

47.0 

— 

.03* 

Check  path  parameters 

103.0 

— 

.02* 

Check  engine 

0.8 

— 

.00 

Check  sonar  range 

303.0 

— 

.06 

*Note:  Values  with  *  represent  significance  at  a=.05 


As  a  final  means  of  comparison,  one-sample  t-tests  were  conducted,  comparing  the 
responses  to  the  estimate  for  the  MSAT  to  determine  if  there  was  a  significant  difference 
(Table  4).  For  some  tasks,  the  distribution  of  responses  was  highly  skewed.  Thus,  the 


1  The  pay  rates  were  taken  from  http://www.dfas.mil/militarvpav/militarvpavtables.html.  which  provides 
military  pay  information  for  different  ranks. 


74 


responses  to  these  tasks  were  analyzed  using  non-parametric  statistics,  specifically  a 
single  sample  sign  test.  Type  I  error  was  set  at  a=0.05. 

These  values  show  that  in  many  different  areas,  the  MSAT  offers  both  a  statistically  and 
a  practically  significant  advantage  over  current  methods.  For  those  tasks  that  are  not 
significantly  different,  there  may  still  be  advantages.  For  one,  the  graphs  for  survey 
responses  show  that  variability  with  current  methods  is  high,  and  the  MSAT  may  offer 
more  consistent  results.  Also,  high  variability  and  limited  responses  make  it  difficult  to 
show  significant  differences.  The  variability  for  each  task  can  be  seen  in  Appendix  J. 

Based  on  the  results  of  the  time  and  motion  study,  there  are  many  tasks  that  can  benefit 
from  use  of  the  MSAT.  Time  savings  are  seen  for  each  of  the  tasks  associated  with  the 
time  and  motion  study,  and  using  automation  can  also  help  to  reduce  the  variability  in 
task  times.  The  overall  benefit  of  the  MSAT  can  be  seen  in  the  time  savings  across  all  of 
the  tasks,  which  can  lead  to  a  shift  in  responsibilities  or  possibly  reduced  manning.  These 
results  show  areas  where  automation  can  aid  current  users  across  the  submarine.  From 
these  responses,  navigation  and  its  subtasks  seem  to  benefit  from  the  aid  of  automation. 
In  order  to  see  what  time  savings  and  efficiency  increases  may  be  seen,  a  more  specific 
navigation  test  was  also  performed.  These  results  are  discussed  in  the  next  section. 

5.2  Navigation  Experiment 

The  results  of  the  navigation  experiment  also  revealed  many  benefits  of  MSAT.  Based  on 
the  2x2  ANOVA  results  for  task  duration,  it  can  be  seen  that  the  time  taken  to  plot  a  path 
is  significantly  less  using  the  MSAT  as  opposed  to  paper  charts  for  both  military  and 
civilian  users  (F(l,14)=92.47,  pc.OOOl).  There  was  also  no  interaction  effect  (p>.05).  The 
supporting  ANOVA  tables  can  be  found  in  Appendix  K.  The  factor  mean  time  spent 
using  the  MSAT  was  just  over  1.5  minutes,  with  the  average  time  used  for  the  paper 
charts  nearly  4  minutes.  These  results  are  separate  from  the  time  and  motion  study,  which 
focused  on  real  world  scenarios  which  can  be  much  more  complicated.  The  navigation 
experiment  was  a  very  basic  navigation  scenario,  so  it  was  expected  that  task  times  would 
be  shorter  than  those  cited  in  the  time  and  motion  study.  The  experiment  also  provides 
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objective  results,  unlike  the  subjective  answers  provided  for  the  time  and  motion  study. 
Figure  23  shows  that  there  were  slight  differences  in  time  between  military  and  civilian 
users,  but  that  the  overall  time  was  much  less  for  the  MSAT.  Because  these  results  are 
based  on  actual  experimental  data,  they  are  far  more  realistic,  and  should  be  weighted 
more  than  the  time  and  motion  study  estimates. 
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Figure  23:  Total  Time  for  Plotting  a  New  Course 
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Similarly,  there  was  also  a  significant  difference  between  the  MSAT  and  paper  charts  for 
the  length  of  the  paths  (F(l,14)=  13.21,  p=.003).  These  lengths  were  calculated  by 
subtracting  the  most  direct  path  length  that  avoided  obstacles  from  the  length  of  the  user 
created  path  (Figure  24).  This  scaled  the  results  so  that  they  could  be  compared  across  the 
two  scenarios.  On  average,  the  MSAT  planned  paths  were  approximately  five  nautical 
miles  shorter,  which  is  about  7%  of  the  total  distance.  Also,  it  was  noted  that  for  path 
length,  there  was  a  significant  difference  between  military  and  civilian  users 
(F(  1 , 14)=1 8.26,  p=.001).  The  military  members  planned  longer  paths,  which  tended  to  be 
more  conservative  near  contacts.  The  shorter  paths  created  by  the  MSAT  were  overall 
more  efficient,  leading  to  both  time  savings  and  decreased  operating  costs.  Again,  there 
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was  no  interaction  effect  (p>.05).  The  ANOVA  tables  can  be  found  in  Appendix  K.  With 
regard  to  obstacle  avoidance,  there  was  no  difference.  None  of  the  participants  plotted 
paths  that  intersected  obstacles  on  the  MS  AT  or  on  the  paper  charts. 
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Figure  24:  Path  Length  Comparison 


After  the  navigation  experiment,  a  trust  questionnaire  was  administered.  The  primary 
focus  of  this  questionnaire  was  whether  participants  were  willing  to  trust  the  MSAT.  The 
overall  results  were  positive.  Responses  ranged  from  1  (no  trust)  to  5  (complete  trust), 
and  most  subjects  reported  having  some  amount  of  trust.  Although  only  one  participant 
reported  having  complete  trust,  the  general  trend  was  that  the  tool  was  trusted,  as  only 
two  participants  reported  having  less  than  an  average  amount  of  trust  in  the  MSAT. 
Based  on  a  Mann- Whitney  test,  there  was  no  significant  difference  between  military  and 
civilian  responses  for  trust  (U=25.5,  p=.50).  These  results  are  shown  in  Figure  25. 


Other  analyses  were  performed  to  determine  if  there  were  additional  trends  in  the  data. 
Based  on  the  HCTA  and  interviews  with  SMEs,  it  was  expected  that  the  military  users 
would  be  more  likely  than  civilians  to  use  the  manual  MSAT  method,  rather  than  trusting 


77 


the  automation.  A  marginal  correlation  was  seen  (Spearman’s  p=.39),  but  there  was  no 
significance  (p=.13,  4/8  military  subjects  used  the  manual  method,  1/8  civilians  used 
manual  method). 
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Figure  25:  Overall  Trust  in  System 

The  next  comparison  investigated  whether  there  were  any  correlations  among  subjects 
who  used  low,  medium  or  high-risk  paths  (based  on  separation).  Four  different  factors 
were  checked  using  the  Spearman  rank  test  to  see  if  there  was  a  relationship  among  the 
following:  age,  civilian  or  military  background,  maritime  experience,  and  charting 
experience.  After  checking  for  significant  correlations,  none  were  found  (supporting 
statistics  in  Appendix  K3).  The  Spearman  rank  test  was  used  because  the  assumption  of 
normality  was  not  met  by  any  of  the  predictor  variables.  The  lack  of  significance  could 
simply  be  due  to  the  relatively  low  number  of  subjects,  but  could  also  indicate  that  a 
subject’s  willingness  to  accept  risk  is  not  strongly  tied  to  factors  such  as  age,  experience, 
and  training. 

The  next  test  checked  to  see  if  there  was  any  relationship  among  users’  responses  on  the 
trust  questionnaire  and  their  risk  level  for  the  path  used.  The  assumption  was  that  users 
who  had  higher  trust  in  the  automation  would  be  more  willing  to  accept  high-risk  paths, 
and  vice-versa.  The  responses  for  questions  regarding  the  trust,  reliability,  and 
accurateness  of  the  MSAT  (Appendix  I)  were  assessed  for  a  relationship  between  the 
different  risk  levels,  using  the  Spearman  Rank  correlation.  All  values  were  based  on  a 
five  point  scale,  and  based  on  this  test,  none  of  these  responses  showed  significant 
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correlations  (Appendix  K3).  Based  on  these  results,  there  does  not  seem  to  be  a 
significant  relationship  between  how  much  someone  trusts  the  MSAT  and  the  level  of 
risk  they  are  willing  to  take.  A  table  showing  some  of  the  descriptive  statistics  for  this 
test  is  shown  in  Appendix  K4. 

Finally,  the  last  set  of  tests  performed  was  a  regression  analysis,  to  see  if  there  were  any 
significant  predictor  variables  for  high  performance.  Age,  years  charting  and  risk  were  all 
checked  for  significance  for  both  path  length  and  time  while  controlling  for  tool  type, 
background,  and  their  interaction.  A  mixed  linear  model  was  built  with  the  following 
factors:  tool  type  (MSAT/paper),  background  (civilian/military),  and  tool  type  and 
background  interaction,  as  well  as  the  following  covariates:  age,  charting  experience,  and 
risk  level.  None  of  the  covariates  were  found  to  be  significant  (p>.2).  Overall,  it  appears 
that  the  subjects’  performance  was  not  significantly  dependent  on  age,  charting 
experience  or  level  of  risk.  While  the  lack  of  significance  may  be  due  to  the  relatively 
small  sample  size,  it  may  also  indicate  the  robustness  of  the  MSAT,  suggesting  that 
MSAT  was  simple  and  intuitive  enough  that  people  were  able  to  use  it  regardless  of  past 
experience.  While  age  has  been  seen  to  have  a  significant  tie  to  performance  in  a  mission 
planning  study  (Cummings  &  Guerlain,  2007),  the  fact  that  age  did  not  affect 
performance  with  the  MSAT  could  be  a  beneficial  result,  indicating  the  ease  with  which 
users  were  able  to  learn  the  system. 
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6.  System  Implementation 

Based  on  the  results  of  the  time  and  motion  study  and  navigation  experiment,  it  is  clear 
that  the  MSAT  can  provide  advantages  to  submarine,  and  more  generally,  maritime 
crews.  However,  there  are  still  many  issues  for  system  implementation  that  must  be 
addressed  before  the  MSAT  can  become  operational.  This  chapter  raises  many  of  these 
questions  by  looking  at  the  MSAT  through  several  different  lenses  of  human-system 
integration  (HSI).  Many  of  the  human  factors  issues  were  addressed  in  previous  chapters, 
but  the  other  areas  of  HSI  will  be  discussed  here,  including  but  not  limited  to  manpower, 
personnel,  training,  habitability,  and  survivability.  Finally,  other  issues  specific  to  the 
MSAT  will  be  discussed  with  regard  to  how  they  will  effect  system  implementation. 

6.1  Manpower 

Across  the  military,  an  important  question  being  asked  is  how  to  reduce  manning  and 
shift  responsibility  to  automation  (Frost,  2008;  Roth,  2004).  Reducing  manning  and 
shifting  the  crew  component  to  a  more  technologically  sophisticated  workforce  can  allow 
the  Navy  to  cut  costs  without  losing  capability  (Roth,  2004).  In  the  submarine 
environment,  manning  must  be  determined  as  early  as  possible,  because  space  is  a 
driving  factor.  With  such  a  high  demand  for  space,  crew  size  is  very  important,  as  each 
person  means  an  additional  bunk,  more  room  for  food,  more  oxygen,  and  possibly  even 
additional  facilities  such  as  showers  and  bathrooms.  If  the  MSAT  can  aid  in  manning 
reduction,  this  means  overall  cost  savings  in  the  design  process.  Space  can  be  set  aside 
for  new  technologies,  increased  facilities,  or  even  extra  food  storage. 

The  difficulty  in  determining  manning  requirements,  especially  in  the  submarine 
environment,  is  that  the  tasks  are  dynamic.  When  in  a  typical  monitoring  scenario, 
personnel  requirements  are  minimal.  This  is  often  the  case  during  peacetime,  when  the 
needs  are  very  repetitive  and  well  defined.  During  wartime,  operational  tempo  increases 
and  most  people  on  the  submarine  become  inundated  with  tasks,  which  also  occurs  in 
emergency  situations.  Manning  is  normally  determined  in  the  conceptual  design  phase 
with  the  wartime  tasks  in  mind,  which  often  prevents  designers  from  making  cuts  to 
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personnel.  The  MSAT  can  help  to  perform  tasks  that  are  necessary  for  both  war  and 
peacetime,  such  as  decreasing  the  amount  of  physical  movement  needed  and  speeding  up 
the  processes  of  navigation.  These  savings  could  potentially  lead  to  a  reduction  in  the 
number  of  people  needed  for  both  war  and  peacetime  operations. 

An  alternative  to  reducing  crew  is  to  shift  responsibilities.  Based  on  the  changing  task 
times  using  the  MSAT,  legacy  task  allocation  may  leave  gaps  for  some  members  of  the 
crew  whose  tasks  have  been  automated.  Shifting  these  gaps  through  task  re-allocation  can 
mean  a  more  constant  workload.  For  example,  the  navigator  can  spend  more  time 
monitoring  unknown  contacts,  rather  than  planning  future  paths  for  example,  or  engage  in 
more  mission-specific  tasking.  By  increasing  the  efficiency  of  workflow,  a  tool  like 
MSAT  could  help  to  balance  manning  for  different  operation  tempos. 

6.2  Personnel 

Originally  designed  for  the  CO  of  the  submarine,  it  was  quickly  realized  that  this  tool 
could  aid  other  members  in  doing  their  job  as  well.  The  executive  officer  (XO),  the 
Officer  on  Deck  (OOD),  and  the  lookout  on  the  bridge  could  all  benefit  from  the 
information  the  MSAT  provides.  With  the  flexibility  of  the  tabbed  display,  many  others 
can  also  benefit  from  this  type  of  mobile  tool.  The  capabilities  of  the  MSAT  also  raise 
further  questions. 

For  one,  the  cost-benefit  ratio  would  need  to  be  determined  to  see  who  should  have  the 
tool.  Although  everyone  on  board  might  find  it  useful,  it  may  be  an  unnecessary  cost  to 
give  one  to  every  member  of  the  crew.  However,  with  advances  in  computing  power,  a 
similar  display  design  could  be  put  into  a  smaller  platform,  such  as  the  new  touch  screen 
mobile  phones.  At  the  very  least,  the  software  needs  for  each  crew  member  may  differ. 
The  CO  and  XO  might  want  to  use  the  same  original  design,  which  shows  a  very  broad 
and  shallow  view  of  systems  across  the  ship.  The  OOD  might  want  the  same  views,  or  he 
might  want  to  see  additional  tabs  to  represent  sonar  or  radar  displays.  For  the  Engineering 
Duty  Officer  (EDO),  the  requirements  might  be  very  different.  The  EDO,  who  spends  his 
time  monitoring  the  nuclear  reactor  on  board,  may  want  more  information  on  turbine 
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generators  and  valve  positions.  Determining  the  right  mix  of  applications  as  well  as 
security  issues  for  various  echelons  of  personnel  on  a  vessel  is  an  area  that  needs  further 
exploration. 

6.3  Training 

The  benefit  of  designing  a  simple  to  use,  intuitive  tool  like  the  MSAT  is  that  the  training 
process  may  be  less  intensive  than  current  paper  and  pencil  methods.  The  users’  manual 
seen  in  Appendix  F  is  short,  and  the  tool  has  few  hidden  functions,  allowing  easily  access 
to  most  of  the  interactions.  In  order  for  users  to  obtain  the  knowledge,  skills,  and  abilities 
necessary  to  operate  the  MSAT,  users  would  face  a  straightforward  process  of 
instruction,  learning,  and  application.  After  becoming  familiar  with  the  users’  manual  and 
the  tool  itself,  users  can  then  learn  how  to  use  the  tool  with  demo  scenarios.  Once 
comfortable  with  these  scenarios,  they  can  begin  to  transition  the  abilities  to  the 
operational  environment. 

Another  additional  benefit  of  the  MSAT  is  that  this  training  process  can  take  place  with 
minimal  costs,  by  simply  giving  the  tool  to  a  person  and  allowing  them  to  try  out  the 
interface.  Simulated  data  can  be  used,  showing  realistic  output  on  the  MSAT  to  train  for 
specific  scenarios.  Because  the  MSAT  is  designed  to  share  information  with  the  other 
displays  on  the  submarine,  crews  can  be  trained  individually  without  having  to  bring  the 
whole  control  room  together.  Once  the  member  is  ready,  he  can  easily  transition  to 
working  with  the  team  using  the  MSAT  in  the  same  way.  Based  on  the  navigation 
experiment,  users  were  able  to  learn  how  to  use  the  navigation  interface  in  just  one  short 
ten  minute  training  session.  To  learn  the  entire  tool  could  take  as  little  as  one  hour.  After 
this  initial  training,  the  member  would  be  ready  to  use  the  MSAT  to  aid  in  current 
responsibilities. 

The  added  training  for  the  MSAT  is  fairly  minimal,  and  it  is  possible  that  other  training 
changes  may  result.  For  one,  training  for  other  systems  can  be  accomplished  using  the 
MSAT  as  a  training  interface.  Since  a  great  deal  of  training  for  the  Navy  is  computer 
based,  these  programs  could  be  incorporated  into  the  MSAT  so  members  can  stay  current 
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with  training  during  downtime.  In  addition,  with  the  ability  to  plan  and  plot  a  path  with 
just  the  click  of  a  button,  certain  tasks  such  as  paper  navigation  become  less  useful. 
Although  important  to  have  in  case  electronic  systems  go  down,  the  time  spent  teaching 
crews  how  to  plot  on  paper  charts  can  be  reduced  to  leave  more  time  for  other  training. 
Crews  can  also  be  trained  in  recognizing  off-nominal  situations,  so  that  the  Health  and 
Status  monitoring  tab  in  the  MSAT  can  further  aid  in  providing  quick  warnings. 

6.4  Habitability 

The  impact  of  the  MSAT  to  habitability  is  fairly  straightforward.  Because  the  MSAT 
allows  increased  mobility  and  gives  up-to-date  information  on  many  systems,  the  MSAT 
provides  a  greater  quality  of  life  for  supervisors  of  submarines.  The  CO  can  stay  up-to- 
date  while  not  engaged  in  a  specific  task  by  simply  keeping  the  MSAT  nearby.  The  OOD 
can  have  increased  flexibility  of  maintaining  situational  awareness  even  if  he  has  to  leave 
the  control  room.  Of  course,  the  MSAT  only  provides  high-level  information,  so  it  is  still 
necessary  to  be  in  the  control  room  during  major  operations. 

The  quality  of  work  could  also  increase  with  the  MSAT.  Beyond  normal  functions, 
further  capabilities  such  as  video  monitoring  of  different  locations  on  the  submarine 
could  help  the  commander  stay  involved.  The  display  could  be  updated  with  a  new  tab  to 
display  this  video  feed  information,  if  desired.  Although  the  small  screen  size  prevents 
complete  control  capability,  the  commander  can  use  the  information  to  determine 
whether  or  not  movement  to  the  control  room  is  necessary  or  simply  use  the  information 
to  start  thinking  of  solutions  en  route.  There  are  many  more  opportunities  to  increase 
quality  of  work  through  the  MSAT.  As  mentioned  in  previously,  there  are  many 
functions  on  the  submarine.  Not  all  of  these  were  addressed  in  the  current  version  of  the 
MSAT,  but  following  the  design  process  outlined  in  Chapter  3  can  lead  to  additional  tabs 
that  can  support  all  functions  across  the  submarine.  Any  or  all  of  these  additional 
capabilities  of  the  MSAT  would  aid  in  habitability  through  the  resulting  increase  in 
quality  of  work. 
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6.5  Survivability 


The  MSAT  will  also  do  a  great  deal  to  increase  survivability  through  the  health  and  status 
monitoring  abilities.  This  tool  allows  for  user- initiated  warnings  for  items  such  as 
atmospheric  levels  and  air  pressures,  which  keeps  commanders  in  the  loop  by  allowing 
them  to  set  levels  with  which  they  are  comfortable.  Also,  the  aggregation  of  information 
keeps  the  commander  up  to  date  on  the  system  status  throughout  the  ship,  allowing  for 
quick  actions  if  something  begins  to  go  wrong.  This  constant  access  to  updated 
information  can  prevent  gaps  in  the  commander’s  situational  awareness. 

6.6  Other  Issues 

Many  of  the  other  issues  with  implementation  of  the  MSAT  deal  with  the  hardware  and 
software  required  to  support  such  a  tool.  Hardware  and  software  implications  are  not  a 
part  of  the  typical  HSI  model,  but  because  of  the  significant  implications  of  the  MSAT, 
they  are  discussed  here.  These  issues  range  from  security  issues  such  as  using  wireless 
communications  to  software  integration  with  current  systems.  There  is  also  the  issue  of 
adding  a  server  to  support  the  MSAT,  which  brings  with  it  another  set  of  issues  entirely. 

The  first  question  is  how  to  support  the  MSAT  via  a  wireless  network.  With  the  need  for 
information  security  at  a  constant  high,  wireless  is  always  a  risk  because  of  the  lack  of 
network  security.  The  fear  is  that  the  wireless  signal  might  “leak  out”  when  the 
submarine  is  surfaced,  and  someone  nearby  might  be  able  to  gain  privileged  information. 
Although  wireless  will  never  be  as  secure  as  wired  communication,  research  has  shown 
that  it  can  work  within  the  steel  hull  of  the  Virginia  Class  (Wilkins,  2001).  During  the 
short  cruise  on  the  USS  New  Hampshire ,  wireless  access  was  possible  through  a  series  of 
repeaters.  While  surfaced,  crew  members  were  able  to  check  e-mail  and  even  outside 
websites.  If  for  some  reason  the  MSAT  cannot  utilize  this  same  system,  there  are  other 
options. 

One  possibility  is  to  use  a  shorter-range  signal  such  as  Bluetooth.  This  would  prevent 
information  from  leaking  beyond  the  immediate  hull,  as  the  signal  strength  is  very  low. 
Bluetooth  range  is  also  not  entirely  limited,  so  within  the  submarine  the  commander  can 
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remain  mobile.  A  different  option  would  be  to  use  one  of  the  new  technologies  such  as 
magnetic  induction.  This  system  has  approximately  a  range  of  six  feet,  which  is  short  but 
still  unwired.  Stations  could  be  set  up  across  the  submarine  where  information  can  be 
received,  which  would  still  provide  more  areas  outside  the  control  room  than  the  current 
configuration.  If  no  wireless  signal  will  work,  the  last  option  would  be  to  provide 
Ethernet  hookups  at  various  locations,  where  the  user  can  plug  in  to  access  up-to-date 
information.  Similar  to  the  repeaters  that  are  currently  on  board,  this  will  still  benefit 
users  due  to  the  greater  amount  of  information  provided  in  remote  areas  away  from  the 
control  room. 

Another  important  issue  to  consider  is  the  thermal  impact  of  a  new  system.  Because  all  of 
the  heat  on  board  the  submarine  must  be  expelled,  it  is  important  to  limit  the  amount 
generated.  Although  the  MSAT  has  a  small  heat  signature,  a  server  would  be  needed  for 
support,  and  could  potentially  generate  a  significant  amount  of  heat.  The  server  would 
take  in  information  from  different  systems  and  compile  that  information  before  sending  it 
to  the  MSAT.  Contact  information,  speed  and  heading,  and  all  of  the  health  and  status 
information  would  need  to  be  taken  from  other  systems  before  being  sent  to  the  MSAT. 
This  server  must  also  be  designed  to  interface  with  all  of  the  other  submarine  systems. 
Because  the  MSAT  takes  in  information  from  across  the  submarine,  the  server  must  be 
able  to  connect  with  each  system  to  share  information.  With  different  designs  for  fire 
control,  radar,  and  sonar,  the  MSAT  must  be  able  to  connect  with  each  and  pass  that 
information  to  the  commander.  This  would  be  no  simple  task,  as  many  of  the  systems  on 
board  were  designed  at  different  times,  using  different  underlying  codes. 

One  of  the  hardware  issues  specific  to  the  MSAT  is  battery  life.  The  current  Sony  Vaio 
has  a  battery  life  of  approximately  4  hours  during  normal  operation.  Ideally,  this  duration 
would  be  increased  to  last  the  length  of  a  normal  6-hour  shift.  Through  upgrades  such  as 
solar  powered  charging  and  lithium  ion  batteries,  this  may  be  possible.  It  would  also  be 
important  to  provide  many  charging  stations,  so  that  the  tool  is  ready  to  use  for  the  next 
person.  Other  options  include  changing  the  supporting  hardware,  as  new  platforms  such 
as  the  iPhone®  boast  a  battery  life  up  to  six  hours  with  continuous  wireless  use. 
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The  software  for  the  MSAT  would  also  need  to  be  continually  upgraded  to  account  both 
for  software  improvements  but  also  new  task  applications.  In  addition,  other  abilities  such 
as  increased  viewing  capability  and  electronic  dead  reckoning  would  also  be  important  to 
incorporate. 

The  need  for  further  work  on  the  MSAT  is  clear  if  it  is  going  to  have  any  future  aboard 
the  submarine.  However,  this  initial  research  shows  many  clear  benefits.  The  crew  can 
benefit  from  an  increased  quality  of  work,  training  can  be  streamlined,  and  information 
becomes  accessible  across  the  submarine.  Identifying  the  hurdles  that  still  need  to  be 
overcome  is  an  important  step  in  the  process  of  implementing  a  mobile  system  onboard. 
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7.  Conclusion 


Recent  news  shows  an  alarming  number  of  avoidable  maritime  accidents,  especially 
within  the  nuclear  submarine  community.  These  accidents  have  occurred  even  with  new 
advances  such  as  the  Virginia  class  and  the  Automatic  Identification  System  for  tracking 
ships  at  sea.  The  fact  that  these  collisions  are  still  occurring  indicates  the  need  for  help. 
Based  on  a  cognitive  task  analysis  of  current  submarine  operations,  including  a  five-day 
cruise  and  interviews  with  various  Naval  officers,  the  existing  shortcomings  were 
identified.  One  central  problem  is  how  information  is  gathered  and  presented  to  the 
commander,  due  to  disjointed  sources  and  lack  of  communication  between  certain 
operators.  Other  problems  relate  to  the  difficulty  of  monitoring  systems  across  the 
submarine,  as  there  is  no  convenient  way  to  track  all  of  the  different  subsystems.  Finally, 
the  bulk  of  information  lies  in  the  control  room,  and  so  it  is  difficult  to  maintain  an 
accurate  mental  model  and  still  have  mobility  across  the  submarine. 

After  recognizing  these  shortcomings,  design  requirements  were  generated  and  a  mobile 
decision  support  tool  was  designed  to  aid  the  commander  in  operations.  The  goal  was  to 
design  a  tool  to  aggregate  information  and  increase  the  situation  awareness  of  a 
submarine  commander.  In  addition,  inserting  automation  via  an  automated  path  planning 
tool  was  a  primary  design  focus,  which  could  be  especially  helpful  in  the  littoral  regions, 
where  contact  density  and  the  number  of  obstacles  becomes  high.  The  design  of  the  tool 
followed  many  key  design  heuristics  to  integrate  the  information  in  an  easy  to  use 
interface  that  would  require  minimal  training.  Once  the  display  was  designed,  a  two¬ 
pronged  evaluation  approach  was  used. 

The  first  method  was  a  time  and  motion  study,  meant  to  measure  the  capabilities  of  the 
MS  AT  against  current  health  and  status  monitoring  procedures.  The  second  was  a 
navigation  experiment,  comparing  the  MSAT  and  its  automation  against  current  paper 
and  pencil  methods.  Both  experiments  showed  positive  results.  For  the  monitoring  tasks, 
the  MSAT  decreased  the  expected  task  time,  and  also  removed  certain  tasks  requiring 
movement  across  the  submarine.  The  time  savings  are  estimated  at  16  hours  per  day 
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across  the  crew,  based  on  the  average  time  of  the  MS  AT  versus  current  methods.  As  for 
navigation,  the  benefits  are  also  clear.  Use  of  the  MSAT  resulted  in  significantly  shorter 
planning  times,  as  well  as  significantly  shorter  paths.  In  addition,  a  trust  questionnaire 
administered  after  the  test  showed  positive  results  from  both  military  and  civilian  test 
subjects,  indicating  a  willingness  to  trust  mobile  devices  in  the  context  of  navigation. 

The  addition  of  the  MSAT  into  the  submarine  environment  affects  more  than  just 
physical  movement,  navigation,  and  monitoring  tasks.  There  are  many  other  changes  that 
may  be  seen  in  MSAT  implementation.  Training  may  change  due  to  the  new  methods 
available  for  path  planning,  manning  might  decrease,  and  the  quality  of  both  work  and 
life  may  increase  on  the  submarine.  Other  more  challenging  effects  deal  with  the  design 
of  a  server  to  support  the  MSAT,  and  the  additional  heat  signature  of  supporting  one  or 
more  MSATs. 

Although  there  are  still  hurdles  that  must  be  addressed  before  the  benefits  of  the  MSAT 
can  be  fully  realized,  the  need  for  improved  decision  support  for  the  commander  is  clear. 
Giving  commanders  the  ability  to  offload  tasks  to  automation,  stay  current  on  the 
surroundings  anywhere  on  the  submarine,  and  easily  monitor  systems  on  an  intuitive 
device  that  fits  in  the  palm  of  a  hand  is  a  possible  solution  to  these  problems.  Based  on 
the  initial  tests  performed  in  this  research,  the  MSAT  can  provide  current  and  future 
commanders  with  the  support  needed  to  gain  higher  levels  of  safety  and  situation 
awareness. 

7.1  Future  work 

The  first  steps  towards  the  use  of  a  mobile  decision  support  tool  have  been  taken,  but 
further  actions  are  required.  Future  work  is  broken  down  into  the  following  three 
sections:  MSAT  design  changes,  system  development,  and  additional  uses. 

The  first  step  in  moving  forward  with  the  MSAT  in  an  operational  environment  is  to 
complete  the  display  design  and  add  functionality  as  needed.  For  example,  different 
information  for  health  and  status  monitoring  may  be  necessary  based  on  new  systems. 
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Also,  more  information  can  be  added  to  the  map  display,  and  the  Rite  View  interface,  or 
some  other  3D  viewer  needs  to  be  incorporated  to  offer  full  viewing  capability.  The 
contact  summary  on  the  overview  tab  also  needs  to  be  updated,  allowing  the  system  to 
show  all  surrounding  contacts  and  adding  the  ability  to  scroll  through  the  information. 
One  way  to  do  this  is  with  the  aid  of  advanced  automation.  By  aggregating  information 
from  different  sensors  on  the  submarine,  contacts  could  show  up  automatically  depending 
on  whether  or  not  a  reliable  signal  has  been  detected.  If  the  MSAT  were  to  be  used  in  a 
control  setting  rather  then  just  an  advisory  took,  further  experiments  should  be  conducted. 

The  next  area  is  dealing  with  the  design  of  the  supporting  hardware  and  software.  In 
order  to  support  the  MSAT  with  the  needed  information,  a  server/client  system  needs  to 
be  created.  The  server  size  will  vary  based  on  the  number  of  mobile  devices  used. 
Regardless  of  size,  the  biggest  issue  will  be  designing  a  system  that  can  communicate 
with  the  current  technology  on  the  submarine  to  take  information  from  the  other  systems 
and  pass  it  to  the  MSAT.  The  current  VMS  system  can  compile  this  information,  but 
further  updates  are  needed  to  combine  contact  information  from  sonar,  radar,  and  visual 
inputs  to  determine  the  most  likely  surrounding  contact  picture.  Once  a  server  is 
designed,  a  method  for  passing  this  information  must  be  chosen.  Wireless  is  the 
recommended  method,  but  based  on  the  issues  with  security,  other  options  such  as 
Bluetooth  and  short-range  magnetic  induction  systems  may  need  to  be  considered. 

Finally,  there  is  an  opportunity  to  modify  the  MSAT  to  work  in  other  areas.  The 
transition  to  surface  ships  is  likely  the  first  update,  but  other  operations  can  also  benefit 
from  the  idea  of  the  MSAT.  Beyond  the  Navy,  commercial  ships  could  also  use  the 
MSAT,  with  a  few  design  changes.  Commercial  ships  would  especially  benefit  from  the 
mobility,  as  many  of  the  large  tanker  ships  operate  with  very  small  crews.  Outside  of  the 
maritime  environment,  other  tasks  that  require  mobile  information  and  monitoring  could 
potentially  benefit  from  the  MSAT.  Hospital  staff,  police,  and  fire  fighters  are  just  a  few 
professions  that  may  be  able  to  use  a  tool  like  the  MSAT. 
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The  MSAT  is  not  yet  ready  for  implementation  in  all  respects,  but  through  this  research, 
the  opportunities  and  issues  available  are  better  understood.  With  the  continuing 
problems  in  the  submarine  community  in  navigation  and  collision  avoidance,  the  need  for 
safer  operations  is  more  than  apparent.  The  MSAT  is  just  one  aspect  of  a  solution,  but 
based  on  the  results  of  this  research,  it  adds  a  clear  benefit  to  the  operational  picture. 
Through  the  implementation  of  a  mobile  decision  support  tool,  submarine  commanders 
can  increase  their  situational  awareness,  make  decisions  more  quickly,  and  operate  from 
all  areas  of  the  submarine  to  improve  both  the  efficiency  and  safety  of  operations. 
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Appendix  A:  Scenario  Task  Overview 


Collision  Avoidance  during  Surface  Operations 


It  is  assumed  that  the  following  issues 
will  be  resolved  in  this  phase: 

Helpful  information  for  resolving  these 
issues  includes: 

Mission 

Planning 

-  Objectives  for  mission  will  be 
determined 

-  Path  desired  will  be  set 

-  Traffic  patterns  in  navigation  area 
will  be  known 

-  Expected  contacts  list  generated 

-  Land  map  is  known  and  accurate 

-  Known  current  and  predicted 
weather 

-  Restricted  areas  defined 

-  Force  Protection  level 

-  Start  and  ending  locations 

-  Possible  paths  provided,  allowed 
variance 

-  Shipping  routes  that  might  be  crossed 

-  Current  traffic  in  the  area 

-  Terrain  map  in  all  possible  travel  areas 

-  Up-to-date  weather  and  current 
information 

-  Military  operations  or  wildlife 
restrictions 

-  Coastal  maps 

-  Assistance  that  comes  along  with  each 

FP  level,  such  as  high  speed  patrol  boats 
to  intercept  vessels 

Phase  Goals 

Phase  Breakdown 

Exit  Harbor 

-  Cast  off  from  docking  position 

-  Orient  craft  to  exit  path 

-  Check  for  contacts  in  area 

-  Follow  navigational  aids  to  exit  harbor  while  following  rules 
of  the  road 

-  Determine  whether  to  stall  or  change  direction  if  path  is 
blocked 

-  Determine  whether  to  change  path  or  wait  for  tides  to  change 
if  depth  is  an  issue 

-  Exit  harbor  phase  is  complete  when  the  craft  is  outside  the 
confines  of  the  docking  area 

Mission 

Execution 

Terrain 

Confined 

Navigation 

-  Set  up  possible  course 

-  Determine  potential  obstructions  both  under  and  above  water 

-  Determine  whether  stopping  or  slowing  is  better  based  on 
currents  and  navigation  ability,  if  traffic  is  heavy 

-  Determine  from  the  mission  time  constraint  whether  there  is 
any  ability  to  slow  down  passage 

-  Determine  what  contacts  may  cause  interference  based  on 
realistic  path  prediction  based  on  past  experience 

-  Determine  limitations  on  contact  maneuverability 

-  Determine  possible  paths  for  burdened  vessel  to  compare 
with  actual  path 

-  Phase  completed  when  avoiding  contact  with  terrain  is  no 
longer  the  primary  concern 

(continued  on  next  page) 
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Mission 

Execution 

Phase  Goals 

Phase  Breakdown 

Open  Water 
Navigation 

-  Set  desired  path 

-  Check  contact  list 

-  Get  Automatic  Identification  System  (AIS)  information  for 
crafts  when  available 

-  Generate  predicted  path  for  contacts 

-  Set  desired  speed  and  possible  checkpoints 

-  Determine  what  variance  is  allowed  in  the  path,  what  time 
restraints  must  be  met 

-  Be  alert  to  other  contacts  in  the  area,  predicting  their  courses 
and  possibilities  of  collision,  while  ensuring  terrain  is  not  a 
factor 

-  Determine  maneuvering  limitations  for  other  contacts 

-  Understand  who  the  privileged  vessel  is 

-  Understand  structural  and  human  limits  on  turning  and 
course  change  maneuvers 

-  Open  water  navigation  phase  is  complete  when  entering  port 

or  coming  in  range  of  shallow  water  where  land  contact  is 
possible.  This  range  is  determined  by  the  size  and  speed  of 
the  craft 

Coming  to 
Periscope 
Depth 

-  Determine  most  likely  current  position  and  possible  surface 
area 

-  Prepare  craft  for  surfacing 

-  Set  desired  ascent  rate  and  speed 

-  List  purposes  for  surfacing  (navigation,  communications, 
maintenance,  etc.) 

-  Check  sea  state  and  environmental  conditions 

-  Brief  all  sensor  operators  of  plan 

-  Perform  all  required  tasks 

Mission 

Recovery 

Return  to 

Port 

-  Once  no  more  mission  execution  phases  are  scheduled,  the 
return  to  port  mission  recovery  stage  begins 

-  Ensure  all  systems  are  in  final  position,  no  weapons  systems 
are  still  active 

-  Path  is  displayed  to  commander 

-  Possible  traffic  hold  ups  determined 

-  Tide  issues  are  checked  to  see  if  they  will  change  plans 

-  If  crew  is  fatigued  or  near  shift  change,  then  check  whether 
docking  should  be  pushed  forward  or  delayed 

-  Check  for  harbor  restrictions  based  on  craft  size,  type,  and 
space 

-  Determine  the  loiter  time  available  outside  the  harbor 

-  This  phase  is  complete  when  the  craft  is  secure  and 
propulsion  mode  is  off 
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Appendix  B:  Event  Flow  Diagrams 

B.l  Event  Flow  Diagram:  UUV  Exit  Harbor 
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B.2  Event  Flow  Diagram:  Restricted  Water  Navigation 
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B.3  Event  Flow  Diagram:  Unrestricted  Water  Navigation 
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B.4  Event  Flow  Diagram:  Return  to  Port 


Appendix  C:  Situational  Awareness  Requirements 


Phases 

/Events 

Level  1 
(Perception) 

Level  2 

(Comprehension) 

Level  3 
(Projection) 

Exit  Harbor 

-  Geo- spatial  boundaries  (PI,  P2,  P4, 

P5) 

-  Alert  of  when  craft  is  free  from  dock 

(pi) 

-  Visual  information  of  navigational 
roadway  (P2,  P4,  P8) 

-  Hazardous  area  (D2,  P5) 

-  Indication  of  thrust/direction  status 
(P2,  P9) 

-  All  contacts  positioning  information 
(Dl,  P3) 

-  Current  position/velocity  information 
(P20) 

-  Indication  of  privileged  vessel  (P9) 

-  Tide  and  current  information  (P4) 

-  Sensor  data  on  surrounding  objects 
(D2) 

-  Current  time  and  mission  timeline 
(D3) 

-  Indication  of  maneuvering  ability  of 
craft  (D4) 

-  Flag  status  of  all  contacts  (restricted 
maneuvering,  etc.)  (P9) 

-  Visual  location  of  craft  on  path 
(P2) 

-  Possible  dangerous  areas  based 
on  tides/currents  (P4) 

-  Visual  information  on  contact 
position/direction  with  relation 
to  operator  (Dl) 

-  Visual  warning  if  path  is 
blocked  (D2) 

-  Warning  if  time  constraints  are 
not  being  met  (D3) 

-  Where  mission  status  is 
temporally  with  respect  to  plan 
(D3) 

-  List  recommended  course 
changes  if  path  is  blocked  (D4) 

-  Indication  of  status  of  pilot 
(onboard/off)  (P10) 

-  Indication  of  status  of  escorts 
(active/disengaged)  (P6) 

-  Readiness  of  security  and  tug 
boats  (P6) 

-  Predict  future  path  of 
contacts  (P3) 

-  Predict  possible  collision 
courses  (D2) 

-  Future  tide  and  current 
information  (D2) 

-  Timeline  with  predicted 
success/failure  of  meeting  time 
constraint  (D3,  P7) 

-  Ability  to  compare  possible 
route  options  (“what  if’)  (P4, 

D4) 

-  Predict  privileged  vessel  for 
future  collision  courses  (P9) 

-  Visual  indication  of  current 
route  in  geo-spatial  context 
(P8,  P9) 

-  Indicate  expected  offload 
location  for  pilot  (P10) 

Restricted 

Water 

Navigation 

-  Visual  information  of  navigational 
roadway  (Pll) 

-  Visually  represent  initial  course  (Pll) 

-  Geo- spatial  boundaries  (PI 2) 

-  All  contacts  positioning  information 
(D5) 

-  Current  time  and  mission  timeline 
(D6,  P18) 

-  Current  contact  path  (PI 7) 

-  Tide  and  current  information  (PI 3) 

-  List  rules  of  the  road  (PI 4) 

-  Flag  status  of  all  contacts  (restricted 
maneuvering,  etc.)  (PI 4) 

-  Indicate  privileged  vessel  (PI 4) 

-  Visual  indication  of  available  paths 
(P16,  P19) 

-  Visual  indication  of  current  path  (P20) 

-  Sensor  data  on  proximity  of 
surroundings  (D9) 

-  Current  position/velocity  information 
(P20) 

-  Warning  if  path  would  overstress  craft 
(D8) 

-  Incorporate  path  with  geo¬ 
spatial  information  to  show 
danger  areas(P12) 

-  Add  contact  data  (position, 
heading)  (D5) 

-  Indicate  temporal  position  on 
mission  timeline  (D6) 

-  Visually  represent  actual 
contact  paths  vs.  predicted  paths 
(PI  7) 

-  Current  structural  stress  on 
craft  vs.  limits  (D8) 

-  Indicate  open  areas  for 
navigation  (PI 9) 

-  Updated  path  information  for 
craft  (PI 6,  P20) 

-  Visual  indication  of  current 
route  in  geo-spatial  context 
(PI  1,  P12,  P20) 

-  Ability  to  compare  possible 
route  options  (“what  if’)  (Pll, 
P16,  P19) 

-  Predict  contacts  future 
position  using  previous  area 
data  for  confined  space  (PI 3) 

-  Predicted  structural  stress  on 
craft  following  set  path  (D8) 

-  Timeline  with  predicted 
success/failure  of  meeting  time 
constraint  (D6,  D7,  PI 8) 

-  Predict  privileged  vessel  for 
future  collision  courses  (P14) 

-  Actual  path  of  contacts 
compared  with  predicted 
paths,  noting  major 
discrepancies  (PI 7) 

Unrestricted 

Water 

Navigation 

-  Visual  information  of  desired  final 
location  and  planned  course(P21) 

-  All  contacts  positioning  information 
(P22,  DIO) 

-  Current  position/velocity  information 
(P24) 

-  Range  to  land/harbor  (Dll) 

-  Contacts  heading,  speed,  and  status 
(given  or  predicted  based  on 
availability  of  AIS  data)  (P23,  P25) 

-  Identify  privileged  vessel  (P27,  D23) 

-  Warning  if  collision  is  possible  (D14) 

-  Warn  if  planned  course  falls  outside 
of  allowable  limits  (D15) 

-  List  variance  from  original  path  (P29) 

-Visual  representation  of  contact 
data  (position,  heading)  (P22, 

DIO) 

-  Incorporate  Automatic 
Identification  System  (AIS)  data 
(ship  status)  (P23) 

-  Indicate  potential  path 
crossings  (P26) 

-  Display  tolerable  variance 
(P29) 

-  Provide  information  noting 
allowable  courses  (D15) 

-  Visual  indication  of  current 
route  in  geo-spatial  context 
(P21,  P24) 

-  Visual  indication  of  contacts 
predicted  paths  using  AIS  data 
(P25) 

-  Ability  to  compare  possible 
route  options  (“what  if’)  (P21, 
P28) 

-  Indicate  possible  collision 
courses  (P26,  D14) 

-  Alert  if  current  path  is 
outside  of  limits  (D15) 
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Level  1-  Perception 

Level  2-  Comprehension 

Level  3-  Projection 

Return  to 

Port 

-  Information  on  pilot  location 
(onboard,  offboard)  (P30) 

-  Visual  representation  of  Geo-spatial 
information  (P31) 

-  System  status  (D16,  P32) 

-  All  contacts  positioning  information 
(D17) 

-  Current  position/velocity  information 
(P33) 

-  Navigational  roadway  information 
(P34) 

-  Tide  and  current  information  (D18) 

-  Right  of  way/privileged  vessel 
information  (P35) 

-  Current  time  and  mission  timeline 
(D21.P37) 

-  Tug  availability  status  (D20) 

-  Docking  status  (D22) 

-  Position  of  escort  boats  (D20,  D21) 

-  Indicate  privileged  vessel  (P35) 

-  Status  of  each  system 
(ready /wait)  (D16) 

-  Indicate  contact  position  and 
heading  (D17,  P33) 

-  Tide  and  current  status  along 
with  go/no  go  limits(D18) 

-  Indication  of  whether  Tug  boat 
assistance  makes  docking 
possible  (D19) 

-  Estimated  time  of  arrival  of 
escort  boats  (D20,  D21) 

-  Indicate  expected  pick-up 
point  for  pilot  (P30) 

-  Predicted  path  of  contacts  in 
area  (P33) 

-  Visual  indication  of  current 
route  in  geo-spatial  context 
(P34) 

-  Future  tide  and  current 
information  (D 1 8) 

-  Timeline  with  predicted 
success/failure  of  meeting  time 
constraint  (D21,  P37) 

-  Future  weather  in  area  (D21) 

-  Ability  to  compare  possible 
route  options  (“what  if’)  (P34) 

-  Predict  privileged  vessel  for 
future  collision  courses  (P35) 
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Appendix  D:  Decision  Ladders 

DL  1:  “Is  desired  course  accessible?”  (D2,  D18) 
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DL  lb:  “Is  desired  Course  Accessible?”  with  display  requirements 
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DL  lc:  “Is  desired  Course  Accessible?”  with  levels  of  possible  automation 


EVALUATE 
Determine 
whether  the 
path  is 
passable 


Possible 

Automation 


Automatically 

INTERPRET 

highlight 

Determine  how 

obstacles  that 

> 

the  obstacles 

are  blocking 

will  affect  the 

path 

path 

1 

| 

Recommendation 

1 

DEFINE  TASK 

J  from  computer 

Course  is 

Determine  a 

/  based  on 

accessible  | 

clear  path  to 

proximity  of 

1 

1 

1 

go 

al 

obstacles  to  path 

Label  all  objects 
on  display , 
either  by  color  \ 
coding  (terrain) 
or  name 
(contacts) 


'll 

IDENTIFY 
Fixed  and  moving 
objects  that  may 
potentially  cross 
path 

IE 


j  No  objects  in 
\  surrounding 


Show  path  and 
objects  on  path 
when  leaving 
port 


Possible  use 
of  automatic 
path  planner 


ACTIVATION 
Planned  path 
is  generated 


Perceive  obstacles  along 
new  path 


EXECUTE 
Follow  new 
path  towards 
goal 


Automatic 
path  planner 
'  re-plans  path 
to  reach  goal 
and  avoid 
collision 


D2,18:  “Is  desired 
course  accessible?” 
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DL  2:  “Would  tug  boat  assistance  make  course  possible?”  (D19) 


D19:  “Would  tug  assistance 
make  course  possible?” 
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DL  2b:  “Would  tug  boat  assistance  make  course  possible?”  with  display 

requirements 

Display  Requirements 


Visual  indication 
if  time 
constraints 
prevent  tug  use 
(highlight  tug 
information  if  it 
can't  arrive  in 
time) 


Jnderstanding  that  problem 
is  constantly  changing  overtime 
and  may  fix  itself 


EVALUATE 
Time  constraints  and 
ability  of  tugs  to 
perform  desired 
maneuvers 


Display  any 
information 
available  on  local 
tug  boats 
(contact  info, 
number  of  boats , 
position , 
estimated  time  to 
arrive ,  etc.) 


IDENTIFY 
Capabilities  of 
tug  boats  in 
area 


List  what  the 

JL 

\ 

_ T _ 

FORM 

problem  (s)  are  l 

OBSERVE 

\ 

PROCEDURE 

with  getting  into 

Determine 

\ 

Determine  how 

port 

what  problem 

\ 

to  contact  tug 

is  (current , 

boats 

tide,  contacts) 

\  1 

Display  status  of 
path  (clear, 
blocked) 


Tug  \ 
assistance  \ 
would  not  \ 
help  ^ 

overcome  \ 
problem 


Decision 
not  to 
use  tugs 


List  allowing 


DEFINE  TASK  userto  add/ 
Finalize  which  [/l,  remove 
tugs  will  be 
needed 


available  tugs 


Knowledge  of  which  tugs 
are  being  requested 


Display  contact 
information  again 


Waiting  to  enter  port 


D19:  “Would  tug  assistance 
make  course  possible?" 
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DL  2c:  “Would  tug  boat  assistance  make  course  possible?”  with  levels  of  possible 

automation 


Possible 

Automation 


Automatically  check 
problem  with  possible 
solutions,  using 
capability  of  tug  boats 
available  vs  current  or 
weather  limitations , 
display  whether  course 
becomes  passable 


EVALUATE 
Time  constraints  and 
ability  of  tugs  to 
perform  desired 
maneuvers 


Provide  list  of  tug 
boats  in  port  that 
are  available 


Automatically 
update  display 
with  tide,  current, 
and  contact  info , 
highlighting  what 
may  prevent 
arrival 


Tug  ' 
assistance  \ 
would  not  \ 


Decision 
not  to 
use  tugs 


DEFINE  TASK 
Finalize  which 
tugs  will  be 
needed 


Automatically 
select  tugs 
that  would  be 
needed  in 
order  to  make 
path  possible 


Knowledge  of  which  tugs 
are  being  requested 


\  | 

FORM 

OBSERVE 

\ 

PROCEDURE 

Determine 

\ 

Determine  how 

what  problem 

\ 

to  contact  tug 

is  (current , 
tide ,  contacts) 

\  1 

\  l 

boats 

Display  the 
I  required  tug 
contact 

1  information  to 
operator 


help  \  | 

ACTIVATION 

overcome  \  • 

EXECUTE 

Path  into  port 

problem  '  . 

Request  tug 

is  inaccessible 

w 

assistance 

Send  automated 
message  to  tug 
boats  requesting 
assistance 


Waiting  to  enter  port 


D19:  “Would  tug  assistance 
make  course  possible?" 
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DL  3:  “Are  there  any  contacts  in  the  area?”  (Dl,  D5,  DIO,  D17) 


EVALUATE 

Determine  possible  contacts 
based  on  what  information 
can  support,  adjust  sensor 
settings  or  request  additional 
sensor  information  if  available 


Recognize  that  some  sensor 
data  can  be  ambiguous 


Recognize  need  to 
track  contacts 


INTERPRET 
Based  on  the  given 
sensor  data , 
determine  if  the 
information  could 
represent  active 
contacts 


DEFINE  TASK 
Finalize  which 
contacts  are  in  the 
surrounding  area 


Perceive  what 
information  may  represent 
ssL.  possible  contacts  / 


IDENTIFY 
Identify  if  data/ 
imagery  is  sufficient  , 
for  identifying  \ 
possible  contacts  \ 

A  \ 

-  Perceive  data/imagery  from  ■ 
sensor  systems 


OBSERVE 
Sensor  data  from 
sonar,  radar,  GPS, 
Satellite  and/or 
Automatic 

Identification  System 
(AIS) 


If  there  are  no 
i  possible 
\  contacts  in 
'(area,  continue 
»  monitoring 


, -Recognize  what  sensor  data - 
V  is  available 


nageryis  \  t 


insufficient 

continue 

monitoring 


Perceive  what  contacts 
are  in  the  area 


FORM 

PROCEDURE 
Log  contacts 
including  range  and 
whether  they  are 
opening  or  closing 


Perceive  state  space 
locations  and  paths  of  all 
contacts  in  area 


_ I _ 

ACTIVATION 
Moving  into  area 
with  possible 

until  situation 
can  be 
perceived 

\ 

r 

_ _ 

EXECUTE 

Plot  the  contacts  location 
and  most  likely  predicted 
path  in  state  space  with 
respect  to  the  operator's 

unknown  contacts 

- <■ 

MONIT 

ORING 

vessel 

ni  i;  ini': 

any  contacts  in  the 
area?” 
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DL  3b:  “Are  there  any  contacts  in  the  area?”  with  display  requirements 


Highlight  on 
map  what 
areas  have 
not  been 
checked  for 
contacts 


ACTIVATION 
Moving  into  area 
with  possible 
unknown  contacts 


EXECUTE 
Plot  the  contacts  location 
and  most  likely  predicted 
path  in  state  space  with 
respect  to  the  operator's 
vessel 


Display 
position  and 
direction  of  all 
surrounding 
contacts  with 
respect  to  craft 


D1 ,5,10,17:  “Are  there 
any  contacts  in  the 
area?” 
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DL  3c:  “Are  there  any  contacts  in  the  area?”  with  levels  of  possible  automation 


List  the  contacts 
whose  paths  differ 
from  predicted  path 
in  order  from  highest 
to  lowest  deviation 


Recognize  that  some  sensor 
data  can  be  ambiguous 


EVALUATE 

Determine  possible  contacts 
based  on  what  information 
can  support,  adjust  sensor 
settings  or  request  additional 
sensor  information  if  available 


Show  initial 

guess  at 

contacts, 

INTERPRET 

highlight  which 

Based  on  the  given 

ones  are  \ 

sensor  data , 

uncertain , 

determine  if  the 

show  what 

information  could 

data  is  missing 

represent  active 

or  questionable 

contacts 

Automatically 
go  back  to 
monitoring  if 
no  useful  data 
is  obtained , 
report  no 
contacts 


IDENTIFY 
Identify  if  data / 
imagery  is  sufficient 
for  identifying 
possible  contacts 


If  there  are  no 
possible 
^  contacts  in 
^area ,  continue 
t  monitoring 


OBSERVE 

Scan  sensor 

Sensor  data  from 

data  to  detect 

sonar ,  radar ,  GPS, 

patterns  that 

Satellite  and/or 

could 

Automatic 

represent  a 

Identification  System 

contact 

(AIS) 

Alert  crew 
when  part  of 
surroundings 
is  unknown 


If  data/ 


ACTIVATION 
Moving  into  area 
with  possible 
unknown  contacts 


w 

\  ' 

imagery  is  \  t 
insufficient  '  ' 
continue 
monitoring 
until  situation 
can  be 
perceived 


\  t 
\  \ 

\  t 
\  \ 
\\ 


Possible 

Automation 


DEFINE  TASK 
Finalize  which 
contacts  are  in  the 
surrounding  area 

Automatically  list 
surrounding 
1  contacts 


Automatically  log 
I  this  information 
I  for  all  contacts  in 
the  area 


FORM. 

PROCEDURE 
Log  contacts , 
including  range  and 
whether  they  are 
opening  or  closing 


Perceive  state  space 
locations  and  paths  of  all 
contacts  in  area 


Automatically 

^ _  export  contact 

EXECUTE  information  to 

Plot  the  contacts  location  /  state  space 
and  most  likely  predicted  display ,  showing 
path  in  state  space  with  current  and  likely 
respect  to  the  operator's  future  position 
vessel 


D1, 5, 10,17:  "Are  there 
any  contacts  in  the 
area?" 
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DL  4:  “Is  collision  possible?”  (D14,  D23) 


D14,  23:  “Is  collision 
possible?” 
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DL  4b:  “Is  collision  possible?”  with  display  requirements 


Display 

Requirements 


Visual/auditory 

warning  if  craft  is  1 

EVALUATE 

on  a  collision 

Likelihood  of 

course  with  [ 

collision  based  on 

another  contact 

current  information 

D14,  23:  “Is  collision 
possible?" 


Ill 


DL  4c:  “Is  collision  possible?”  with  levels  of  possible  automation 


D14,  23:  “Is  collision 
possible?" 
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Appendix  E:  Information  Requirements 


Type 

Requirement  Description 

Source 

Geo-spatial  boundaries  (Overview,  Navigation,  Rite-View) 

SA,  DL  4 

Visual  navigation  lanes 

SA 

Hazardous/restricted  areas  (Overview,  Navigation,  Rite-View) 

SA 

Highlight  any  areas  that  have  not  been  searched  for  contacts 

DL  3 

Tide,  current,  weather,  marked  on  display  (Navigation) 

SA,  DL  1 

Future  weather  information 

SA 

o 

Future  tide/current  information 

SA 

c 

Planned  course,  highlighted  red  if  blocked,  green  if  clear  (Overview, 

03 

Navigation) 

SA,  DL  1 ,2,3,4 

C3 

Q. 

(/) 

■ 

o 

Variance  of  actual  path  versus  planned  path 

SA 

Visual  indication  of  allowable  paths  when  helpful  (Navigation) 

SA,  DL  1,4 

0) 

(5 

Mark  final  destination  or  goal  location  on  map  (Overview,  Navigation) 
Ability  to  determine  range  from  ownship  to  other  points  of  interest 

SA,  DL  1 

(Navigation) 

SA 

Position  of  escort/tug  boats 

SA 

Areas  where  collision  is  possible  or  uncertain 

SA 

Indicate  allowed  variance  of  ownship  path 

SA 

Mark  location  of  pilot  pick-up  and  drop-off 

SA 

Most  likely  paths  for  commercial  vessels  (shipping  lanes,  port  roadways) 

SA 

Geo-spatial  location  of  all  surrounding  contacts  (Overview,  Navigation, 

Rite -View) 

SA,  DL  3,4 

Contacts  course  and  speed  (Overview) 

SA,  DL  3 

Specific  sensor  data  available  for  review  (Health  and  Status) 

DL  3 

Highlight  sensor  data  that  most  likely  represents  a  contact  (Overview, 

Navigation) 

DL  3 

o 

M— 

Popup  asking  whether  to  analyze  current  data  for  contacts  or  continue 

c 

monitoring 

DL  3 

o 

(0 

Indication  of  privileged  vessel,  flag  status 

SA,  DL  4 

c 

o 

Q 

Contact  path:  past,  present  and  future  (Overview,  Rite-View) 

SA,  DL  4 

Contact  location  on  path  (Overview,  Navigation,  Rite-View) 

SA 

Marking  to  distinguish  contacts  with  AIS  data 

SA 

List  of  contacts,  with  name,  bearing,  speed,  and  whether  course  is 
opening/closing  (Overview) 

DL  1,3 

Alert  when  contact  enters  area 

DL  4 

Deviations  of  contact  path  versus  what  AIS  data  says 

SA 
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Alerts  and  Feedback 

When  craft  is  free  from  dock 

When  path  would  overstress  vessel  (maneuvering  limitation) 

When  craft  is  on  a  collision  course  with  a  contact  (Navigation) 

SA 

SA 

SA,  DL  4 

SA 

SA 

SA,  DL  2 

SA 

SA 

SA 

DL  2 

SA 

When  planned  course  violates  limits  or  set  restrictions  (Navigation) 

When  systems  are  not  in  final  position  and  heading  for  port 

When  path  is  inaccessible,  also  list  why  (Overview) 

When  time  constraints  are  not  being  met 

When  Tug  assistance  is  available/helpful 

Rules  of  the  road:  ability  to  display  when  unsure 

Highlight  tug  boat  if  it  cannot  arrive  in  time 

Status  of  Pilot 

Current  speed  and  heading  (Overview) 

SA 

Current  time 

SA 

(/) 

Mission  timeline 

SA 

3 

O 

<D 

Predicted  ability  of  meeting  timeline 

SA 

C 

J2 

Availability  of  tug  boats 

SA 

a> 

o 

Current  structural  stress  on  craft 

SA 

c/> 

i 

ETA  of  escort/tug  boats 

SA 

as 

(0 

Recommended  course  changes 

SA 

D 

Information  on  local  tug  boats  (contact  info,  number  of  boats,  position. 

ETA) 

DL  2 

List  of  tug  boats  allowing  user  to  add/remove 

DL  2 

Ability  to  compare  different  routes  (Navigation) 

SA 

Note:  Information  requirements  highlighted  in  gray  are  the  ones  chosen  for 
implementation  on  the  MSAT. 
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Appendix  F:  User’s  Manual 
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1.0  General  Information 


1.0  GENERAL  INFORMATION 
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1.0  General  Information 


1.0  GENERAL  INFORMATION 


1.1  System  Overview 

The  Mobile  Situational  Awareness  Tool  (MSAT)  allows  submarine  commanders  to  maintain  situational 
awareness  while  being  mobile  across  the  submarine.  This  tool  provides  a  variety  of  useful  information, 
including  basic  submarine  status  information  such  as  speed,  position,  and  course,  as  w  ell  as  more  detailed 
health  and  status  information  from  the  air  levels  and  weapons  systems.  In  addition,  the  tool  provides  the 
capability  to  plan  a  path  using  manual  inputs  or  an  automated  function  that  takes  into  account  user  inputs. 

This  system  is  currently  run  as  a  Java  file.  This  program  was  written  specifically  for  the  Sony  Haiti  micro 
PC.  and  so  the  display  size  is  set  to  widescreen  mode  but  the  Java  file  will  work  on  any  display.  Because 
it  is  still  in  a  beta  version,  the  MSAT  works  as  a  standalone  device,  however  in  order  to  be  fully 
functional,  it  would  need  to  be  set  up  with  a  server  on  the  submarine  that  broadcasts  data  to  populate  the 
screens  in  live  MSAT. 

The  system  itself  is  designed  for  submarine  commanders,  but  could  be  adjusted  to  fit  the  needs  of  a 
variety  of  users.  Each  tab  can  be  modified,  and  additional  tabs  can  be  added  to  show  the  waterfall  display 
for  sonar  operators,  radar  plots,  contact  information,  etc.  This  flexibility  was  designed  into  the  tool  to 
allow  for  changing  user  requirements  and  to  aid  in  a  variety  of  mission  types. 

1.2  Project  References 


This  tool  was  designed  by  students  in  the  Humans  and  Automation  Lab.  MIT.  under  Professor  M.L. 
Cummings.  For  more  information  on  tlsc  product  itself,  see  the  completed  thesis  of  Maricla  Buciun 
(February  2009,  MIT)  or  the  thesis  by  Geoff  Camgan  (June  2009.  MIT).  These  can  be  found  on  the 
Humans  and  Automation  Lab  website,  http  w  cb.:. i.i.cdu  acioasiro  jbslialab.  index  .hhtrtil. 

1.3  Acknowledgments 

This  research  was  funded  through  a  Small  Business  Innov  ation  Research  (SB1R)  for  the  Combat  System 
of  the  Future  (CSoF)  in  partnership  with  M11CEL  Inc..  ASSETT  Inc.  and  Rite- Solutions  Inc. 

1 .4  Points  of  Contact 

Humans  and  Automation  Lab 
Bldg  35-220 
7?  Massachusetts  Avc 
Cambridge.  MA  02139 

Professor  Mary  (Missy)  Cummings:  nnssyeig  mii.edu 
Geoff  Carrigan:  Geoffrey  .carngan&gmaiLcocn 
Maricla  Buchin.  maricja.buchinia,gmaiI.coi:i 
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1.0  Central  Information 


1.5  Organization  of  the  Manual 

This  user’s  manual  is  broken  down  into  the  following  sections. 

1.0  General  Information-  This  section  describes  the  overall  tool,  as  well  as  the  background  information 
for  the  project  including  the  designers  and  the  SB1R  “Combat  System  of  the  Future"  through  which  the 
research  w  as  funded. 

2.0  Getting  Started-  This  section  describes  how  to  start  the  program  and  interact  with  the  tool 

3.0  Overview  Tab-  This  section  describes  the  information  provided  in  the  overv  iew  tab  as  well  as  how  to 
use  the  functions. 

4.0  .Navigation  Tab-  This  section  describes  how  to  use  the  navigation  tab  and  what  information  is 
provided. 

5.0  Health  and  Status  T ab-  This  section  describes  bow  to  nav  igate  through  the  various  health  and  status 
information. 

6.0  Rite  View  Tab-  This  section  describes  how  the  Rite  View  tab  works  and  what  information  is 
provided. 

1.6  Acronyms  and  Abbreviations 


CM 

Cruise  Missile 

CPA 

Closest  Point  of  Approach 

CSoF 

Combat  System  of  the  Future 

EMBT 

Emergency  Main  Ballast  Tank 

Ft 

Feet 

GPS 

Global  Positioning  System 

HP 

High  Pressure 

JRE 

Java  Runtime  Environment 

Kts 

Knots 

Lat 

Latitude 

Long 

Longitude 

Min 

Minimum 

MSAT 

Mobile  Situational  Awareness  Tool 

MT 

Empty 

PS1 

Pounds  Per  Square  Inch 
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TH 

Tomahawk  Missile 

TP 

Torpedo 

ROT 

Rate  of  Turn 

RPM 

Resolutions  Per  Minute 

Rud.  Ang. 

Rudder  Angle 

SBIR 

Small  Business  Innovation  Research 

See 

Seconds 

VL 

Vertical  Launch 

Yds 

Yards 
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2.0  (ictlinf.  Started 


2.0  GETTING  STARTED 
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2.0  GETTING  STARTED 


2.1  Software  Code 

The  software  for  the  MSAT  was  developed  using  the  Java  programming  language  in  the  Eclipse 
integrated  development  environment.  The  code  itself  is  highly  modular,  which  allows  any  or  part  of  the 
display  to  be  edited,  replaced,  or  modified.  Background  maps,  controls,  gauges,  and  information  arc 
representative  of  actual  information  that  would  need  to  be  taken  from  sensor  data,  navigation  maps,  or 
other  operational  information  sources.  The  executable  Java  Archive  (JAR)  file  could  be  used  to  show 
how  the  MSAT  looks  in  an  operational  capacity  . 

2.2  MSAT  Hardware 

The  MSAT  is  designed  for  a  mobile  interface,  specifically  the  Sony  Vaio  pictured  below  in  Figure  1. 
Because  of  this,  the  screen  is  best  viewed  under  wide-screen  conditions.  The  specific  Vatu  model  is 
VGN-UX390N.  Since  the  executable  is  a  separate  JAR  file,  it  can  be  run  on  any  machine  that  supports 
Java  with  the  Java  Runtime  Environment  6  or  higher.  This  software  can  be  downloaded  for  free  at 

http:/.'java^un.com.'javasc.;downlo«ds.'index1jsp. 


F  igure  1:  Sony  Vaio 


On  the  Sony  Vatu,  the  interface  with  the  system  works  through  the  use  of  a  stylus.  For  this  reason,  there 
are  no  right-click  features.  Navigating  through  the  different  tabs  is  done  using  either  the  stylus  or  the 
mouse,  which  is  built  into  the  Vaio. 

2.3  Starting  the  Software 

In  order  to  start  the  MSAT  software,  double  click  on  the  executable  file.  Dcmo.jar.  This  program  can  be 
run  from  any  file  location,  but  it  is  typically  run  from  the  user's  desktop.  The  User’s  Manual  will  refer  to 
two  different  versions,  the  Demo  version  and  the  Operational  version.  The  Demo  version  is  the  version 
that  currently  uses  the  .jar  file.  The  operational  version  describes  how  the  tool  would  work  if 
implemented  into  the  submarine  fleet.  In  the  demo  version,  the  submarine  starts  at  the  top  and  lias  a  goal 
position  on  live  bottom.  Once  the  file  is  open,  maximize  it  to  the  screen  (if  using  a  Sony  Vaio  or 
w  idescreen  interface),  or  manually  change  the  size  to  a  widescreen  format  (if  using  a  normal  monitor). 
From  this  view,  any  of  the  tabs  can  be  used  or  interacted  w  ith  by  simply  clicking  on  the  tab  name  at  the 
top.  The  four  different  tabs.  Overview.  Navigation.  Health  &  Status  and  Rite-View  tabs  arc  described  in 
more  detail  in  the  following  sections.  The  initial  startup  screen  is  shown  in  Figure  2. 
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3.0  Q^er>ie*  Tib 


3.0  OVERVIEW  TAB 
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3.0  Overlie**  Tib 


3.0  OVERVIEW  TAB 


3.1  Screen  Layout 


The  overview  tab  is  the  default  tab  displayed  when  MSAT  starts.  This  tab  is  meant  to  show  the  general 
information  a  commander  needs.  A  screenshot  of  the  overview  tab  is  show  n  in  Figure  3. 
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Figure  3:  Overview  Tab 


This  interface  provides  various  pieces  of  information  to  support  the  commander.  The  map  portion  shows 
the  current  position  (blue  U  shape)  (I),  current  path  (black  line)  (2)  with  waypoints  (triangles)  (3).  and  a 
hazard  that  has  shown  up  on  the  map  (red  area)  (-4).  Also,  contacts  arc  shown  as  light  blue  circles  (5). 
w  ith  numbers  on  the  circle,  and  a  vector  showing  their  mov  ement  direction.  The  goal  position  is  shown 
in  yellow  (6). 


At  the  bottom,  the  depth  track  along  the  course  is  shown  (7).  This  shows  the  entire  course  and  waypoints, 
w  ith  the  distance  between  the  top  and  the  plotted  line  representing  the  depth.  A  second  line  (8)  shows  the 
user-specified  minimum  depth  requirement.  This  can  be  changed  using  the  navigation  tab. 


On  the  right  side,  the  compass  show  s  the  current  heading  of  the  ship  (9).  indicated  by  both  the  red  arrow 
and  the  digital  readout  in  the  center.  To  the  right  of  the  compass  is  the  speedometer,  which  is  dual-coded 
w  ith  shading  and  a  digital  readout  in  the  center  (10).  Below  these  arc  updated  latitude  and  longitude 
coordinates  (1 1).  as  well  as  the  current  depth  and  the  minimum  depth  along  the  path  (12).  Finally,  a  table 
of  contact  information  is  shown  at  the  bottom  right  comer  (13).  This  table  docs  not  automatically  update 
in  the  demo  version,  but  the  final  version  would  allow  each  column  to  be  sorted  by  clicking  on  the 
column  beading,  and  a  scroll  bar  on  the  right  could  allow  the  commander  to  scroll  through  the  entire  list 
of  contacts. 
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3.0  (Kmiw  Tab 


3.2  Interaction 

There  arc  no  interactive  features  integrated  in  the  overview  interface.  Most  of  the  information  in  this  tab 
would  be  dynamically  updated  by  a  server  located  in  the  submarine's  control  room.  Although  the  current 
version  does  not  currently  support  any  interactive  features,  the  contact  list  could  be  designed  to  be  sorted 
by  number.  Closest  Point  of  Approach  (CPA)  or  Time  to  CPA  by  clicking  on  their  labels  accordingly. 


MSAT  User's  Manual 


Page  3-2 


126 


4.0  Navigation  I  ab 
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4.0  NAVIGATION  TAB 


4.1  Screen  Layout 

The  navigation  tab  is  highly  interactive,  and  allows  the  commander  to  view  the  current  path  hazards  and 
compare  litem  to  other  paths  created  either  manually  or  by  the  automation.  Figure  4  below  shows  the 
initial  view. 


Overview  Navigation  Health  &  Status  Rite  View 


Figure  4:  Navigation  Tab 


On  this  tab.  the  same  information  is  shown  on  the  map  as  for  the  overview  tab.  In  this  view,  the 
background  map  is  faded  to  prevent  mode  confusion.  One  other  difference  is  that  on  the  Navigation  tab, 
movement  is  frozen  to  prevent  the  settings  from  changing  during  path  planning.  In  the  operational 
version,  movement  could  continue  to  allow  the  commander  to  plan  in  real  time. 
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4.0  Navigation  Tab 


Figure  5:  Navigation  T  ab  Fvpandtd 


Figure  5  shows  tbc  key  areas  of  the  Navigation  Tab.  Along  tbe  bottom,  proposed  paths  can  be  compared 
by  distance  and  time  (1)  (these  will  be  described  in  more  detail  below).  On  tbc  right,  tbe  v  iew  of  different 
paths  can  be  changed  by  checking  their  corresponding  boxes  (2).  L.  M  and  H  Separation  represent  the 
low.  medium  and  high  separation  paths  made  by  the  automation.  Low  separation  paths  allow  for 
movements  closer  to  the  contacts,  and  high  separation  paths  leave  more  space  between  contacts.  If  the 
Autoplan  button  is  used,  all  of  tbc  L.  M.  and  H  paths  are  created,  and  then  the  user  can  compare  them 
w  ith  the  graphs  and  the  navigation  chart  to  choose  the  one  that  best  fits  his  or  her  needs.  Below  the 
checkboxes  arc  tbe  three  different  inputs  for  the  automation,  each  with  a  slider  bar.  These  slider  bars  arc 
shown  on  the  right,  denoted  as  (a),  (b)  and  (c).  The  first  is  minimum  separation  from  obstacles  (a).  This 
user-generated  setting  means  that  all  proposed  paths  will  have  at  least  this  amount  of  distance  between 
ownship  and  any  surrounding  contacts  or  shoal  water.  Next  is  the  minimum  depth  setting  (b)  and 
minimum  visibility  setting  (c).  which  must  also  be  set  by  the  user.  Only  paths  that  meet  these 
requirements  will  be  considered  by  the  automation.  The  two  graphs  show  a  comparison  of  depth  and 
visibility  by  the  paths  that  arc  created  (3).  The  view  above  shows  only  the  current  path,  but  manual  and 
automation  paths  arc  added  to  the  view  as  they  arc  created.  Finally,  the  controls  at  the  bottom  right  arc 
used  to  create  either  manual  or  computer  automated  paths. 

4.2  Interaction 

The  navigation  tab  allows  for  complex  user  interactions.  This  section  will  walk  through  a  hypothetical 
situation  using  both  manual  and  auloplan  modes  for  a  path.  Imagine  the  following  scenario  where  a  ship 
is  past  the  hazardous  area  and  w  ants  to  plan  a  new  course  from  the  current  location  to  the  goal  (as  seen  in 
Figure  6a).  From  here,  either  a  manual  or  autoplan  path  can  be  made.  Starting  with  a  manual  path,  the 
user  would  first  set  the  parameters  for  the  path  using  the  slider  bars  in  Figure  5.  These  would  restrict  the 
points  on  the  map  where  the  user  can  add  waypoints,  to  ensure  that  only  waypoints  that  meet  the  user 
criteria  can  be  created.  Next,  the  user  would  click  on  the  Manual  button,  and  then  click  on  the  map  to 
create  a  scries  of  waypoints  (Figure  6a).  If  the  user  clicks  in  an  area  that  would  violate  the  path  rules  for 
separation,  visibility,  depth  or  land,  a  warning  will  be  displayed  on  the  right  and  the  user  will  have  to 
click  a  new  area,  or  click  Cancel  to  stop  the  path  (Figure  6b). 
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4.0  VaM^atiun  Tab 


Overvmw  Navigation  MoAtth  A  Status  Rita  Vow  Overview  Navigation  Health  A  Statu*  Rite  View 


Figure  6:  Manual  Path 

Once  the  user  is  close  enough  to  the  goal,  the  Finish  button  can  be  clicked  to  complete  the  path.  Once  the 
manual  path  is  created,  the  waypoints  can  be  modified.  Clicking  Delete  will  highlight  all  waypoints  that 
can  be  deleted  without  causing  the  path  to  cross  an  obstacle.  If  no  waypoints  can  be  deleted,  an  error 
message  will  be  displayed.  This  view  is  shown  in  Figure  7.  Clicking  a  highlighted  waypoint  will  delete 
it 
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Fi^urt  7:  No  waypoint*  to  delete 


To  add  a  waypoint,  click  the  Add  button,  and  then  click  on  a  segment  of  the  manual  path.  The  waypoints 
can  then  be  dragged  to  different  locations  to  modify  the  path.  This  is  shown  below  in  Figure  8.  Figure  8a 
shows  a  waypoint  being  added  (highlighted  in  yellow)  and  Figure  8b  shows  that  waypoint  being  moved, 
along  with  the  graphs  that  update  on  the  tight. 
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4.0  Navigation  Tab 


figure  8:  Adding,  Moving  "  av  points 

In  order  to  remove  the  manual  path  from  the  view  (without  deleting  it  from  memory),  dimply  un-check 
the  Manual  box  on  the  top. 

If  the  user  decides  to  create  an  autoplan  path  instead,  he  or  site  must  first  set  the  requirements  using  the 
three  slider  bars  for  separation  distance,  depth,  and  visibility.  The  minimum  and  maximum  values 
allowed  by  the  slider  bars  represent  typical  ranges  used,  based  on  interviews  with  subject  matter  experts. 
After  this,  simply  click  the  Autoplan  button.  This  will  create  the  following  four  paths  on  the  screen 

1 .  Autoplan  (red):  Meets  all  of  the  requirements,  docs  not  account  for  contacts. 

2.  H  Separation  (dark  brown).  Meets  all  requirements,  leaves  extra  room  near  contacts,  best 
for  high  variability  contacts. 

3.  M  Separation  (brown):  Meets  all  requirements,  leaves  moderate  room  near  contacts,  best 
for  medium  v  ariability  contacts. 

4.  L  Separation  (light  brown):  Meets  all  requirements,  leaves  little  room  near  contacts,  best 
for  low  variability  contacts. 

These  paths  can  be  added  removed  from  the  view  space  using  the  corresponding  checkboxes.  All  four  arc 
shown  in  Figure  9. 


MSAT  I'str's  Manual 


Page  4-4 


131 


4.0  Navital  itml  »b 


Figure  9:  Autoplan  Paths 


Once  the  desired  path  has  been  plotted,  it  can  be  selected  to  replace  the  current  path.  To  do  this,  click  the 
Choose  Path  button,  and  select  the  radio  button  next  to  the  path  you  want  to  use  to  replace  the  current 
path.  Clicking  OK  makes  this  path  the  new  current  path,  and  the  process  can  be  repealed  as  many  times 
as  desired  throughout  the  mission.  This  is  shown  in  Figure  10. 
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5.0  Health  and  Stilus  T  ab 


5.0  HEALTH  AND  STATUS  TAB 
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5.0  Health  and  Statin  Tab 


5.0  HEALTH  AND  STATUS  TAB 


5.1  Screen  Layout 


The  health  and  Matas  tab  allows  the  commander  to  monitor  the  complex  systems  of  a  submarine  by 
checking  for  warnings  and  trend  information.  For  the  submarine,  there  arc  a  variety  of  systems  that  the 
commander  must  monitor  and  the  health  and  status  tab  provides  them  with  different  views  for  various 
subsystems.  The  initial  view  is  shown  in  Figure  II. 
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Figure  II:  Health  and  Stains  Tab 


This  tab  shows  a  variety  of  information  on  engine  parameters,  air  levels,  weapons,  hatches  and  sensors. 
Most  of  this  information  is  self  explanatory,  and  easy  to  check  for  warnings.  Levels  in  green  arc 
acceptable,  yellow  arc  caution  levels,  and  red  arc  warning  levels.  The  small  yellow  bars  in  the  Air 
column  arc  adjustable  (1).  and  allow  the  commander  to  be  notified  if  the  lev  el  set  by  the  bar  is  breached. 
The  small  red  bars  arc  fixed  warnings  that  will  initiate  an  alarm  due  to  some  hard-coded  limitation.  The 
circles  represent  torpedo  tubes  (2),  and  filled  in  circles  mean  there  is  some  weapon  in  the  tube.  From  this 
main  page,  any  of  the  systems  can  be  seen  in  greater  detail  using  the  buttons  across  the  top. 

5.2  Interaction 


The  only  interactive  features  of  this  tab  arc  the  small  yellow  w  armng  bars  and  the  larger  buttons  on  top. 
By  clicking  these  buttons,  the  user  can  get  more  in  depth  infomiation  on  any  of  the  systems.  These 
systems  arc  described  in  greater  detail  below. 
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5.0  Health  and  Statu*  Tab 


Engine 

Clicking  on  the  Engine  button  reveals  the  display  below.  This  gives  the  same  information  shown  in  the 
original  view,  but  in  a  larger,  casicr-to-scc  manner.  There  arc  no  user  inputs  for  this  display,  but  the 
contents  could  change  based  on  the  specifics  of  the  submarine. 

Overview  Navigation  Health  &  Status  Rite  View 
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Air 

Clicking  on  the  Air  button  shows  both  the  high  pressure  (HP)  air  measurements  and  the  atmosphcnc 
levels  over  time.  The  digital  readout  on  the  HP  Air  and  Emergency  Mam  Ballast  Tank  (EMBT)  shows 
the  current  value,  and  the  yellow  bar  can  be  moved  to  change  the  point  at  which  the  commander  is 
notified.  The  graph  show  s  the  main  gases  tracked  over  time  w  ith  respect  to  percent  allow  able.  The  red 
bar  (1)  indicated  a  set  warning  level.  This  level  is  fixed  and  cannot  be  changed,  as  it  represents  the 
absolute  minimum  value  allowed.  The  yellow  bar  (2)  can  be  moved  by  clicking  and  dragging  to  move  it 
to  a  new  value.  This  view  is  shown  in  Figure  13. 
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5.U  Health  and  Status  Tib 


Weapons 

Clicking  on  Use  W  eapons  button  shows  a  variety  of  weapons'  information.  The  type  of  munitions  is 
shown  using  standard  abbreviations  (all  abbreviation  arc  defined  on  page  1-2.  This  view  shows  the 
position  of  each  weapon  on  the  rack,  as  well  as  what  is  in  each  tube.  It  also  represents  the  quantity  of  the 
vertical  launch  missiles  on  board.  A  sample  view  is  shown  in  Figure  14. 
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t  illin'  14:  Weapons 


Hatches 

Clicking  on  the  Hatches  button  shows  information  for  the  different  openings  into  the  submarine.  From 
here,  the  commander  can  monitor  whether  each  of  the  entry  points  is  secured.  Tikis  display  could  also  be 
augmented  with  the  ng-for-divc  checklist  to  aid  in  a  quick  check  before  submerging  (see  Figure  IS). 
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Figure  IS:  Hatches 


Sensors 

Clicking  on  the  Sensors  button  shows  the  strength  of  the  sensors.  Since  speed  makes  a  big  difference  for 
sonar,  speed  is  also  shown  in  the  middle.  The  strength  of  signals  coming  from  the  mast  and  GPS  arc 
shown  in  green,  yellow  or  red  to  represent  good,  average  and  poor  signals,  respectively.  The  same 
convention  is  used  for  the  forward  (1).  trailing  (2),  and  side  aperture  (3)  sonar  arrays.  The  effective  range 
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5.11  Htallh  and  Slatui  tab 


for  the  sonar  is  shown  as  a  filled  in  color  (red.  yellow,  or  green)  based  on  Use  maximum  range  possible. 
In  the  view  below,  the  forward  and  trailing  sonar  range  is  !nm  and  0.5 nm.  respectively,  and  this  is  shown 
as  the  filled  in  yellow  circles.  If  the  range  were  operating  at  its  maximum,  the  circle  would  fill  in  the 
entire  outline,  and  would  be  colored  green.  From  any  of  these  pages,  the  user  can  go  back  to  the  main 
health  and  status  tab  by  clicking  on  the  Back  button. 
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6.0  Rile  View  Tab 


6.0  RITE  VIEW  TAB 
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6.0  Rite  Vic*  Tab 


6.0  RITE  VIEW  TAB 
6.1  Screen  Layout 

The  Rite  View  tab  is  a  3D  environment  under  development  by  Rite  Solutions.  The  view  in  the  demo  is 
not  fully  functional,  but  instead  is  a  scries  of  screen  shots  strung  together  to  show  what  the  interface 
would  look  like.  This  interface  allows  for  different  layers  to  be  turned  on  and  off.  and  shows  the 
geospatial  surroundings  to  help  build  the  commander's  mental  model.  Figure  17  shows  a  screen  shot  of 
this  display. 


Overview  Navigation  Health  &  Status  Rite  View 


Figure  17:  Rite  View  Tab 


6.2  Interaction 


As  staled  abov  e,  the  demo  version  of  the  software  does  not  allow  for  any  interaction  w  ith  the  Rite  View 
system.  Additional  functionalities  could  be  activated  in  the  fully  operational  version.  For  example,  the 
current  path  and  contact  picture  could  be  changed  in  time,  allowing  the  commander  to  fast-forw  ard  and 
sec  how  things  might  appear  in  Use  future.  Also,  different  graphical  overlays  could  be  added,  such  as 
shipping  lanes,  paths,  or  weather.  Also,  clicking  oo  different  ships  could  give  their  information,  and  tlsc 
view  could  be  manipulated  to  sec  the  situation  from  different  points  of  view. 

This  is  live  final  tab  in  the  demo  version  of  the  MSAT.  Operationally  ,  different  tabs  could  be  added  for 
different  operators,  as  well  as  additional  functionalities  related  to  other  missions 
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Appendix  G:  Health  and  Status  Display 


A:  Initial  H&S  display 
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B:  Engine  display 
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C:  Air  display 
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E:  Hatch  display 
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Appendix  H:  Time  and  Motion  Study  Questions 


General  Questions 

1 .  How  long  does  it  take  to  get  from  the  stateroom  to  the  control  room? 

2.  How  long  does  it  take  to  get  from  the  Bridge  to  the  torpedo  room? 

3.  How  complete  is  the  CO’s  mental  model  of  his  surroundings  at  any  given  time? 

Navigation 

4.  How  long  does  it  take  to  get  AIS  data  from  a  contact? 

5.  If  a  problem  arises  along  the  current  navigation  path,  how  long  does  it  take  to  notify 
the  CO? 

6.  Are  emerging  hazardous  areas  ever  shown  on  the  navigation  map? 

7.  How  long  would  it  take  to  view  contacts  by  CPA  time/distance? 

8.  How  long  does  it  take  to  change  one  waypoint? 

9.  How  long  does  it  take  to  check  the  different  parameters  (depth,  distance,  time)  of  a 
modified  path? 

10.  How  long  does  it  take  to  plot  a  completely  new  path? 

11.  How  much  time  is  spent  planning  backup  paths  on  shore  in  case  of  problems? 

12.  How  many  backup  paths  would  typically  be  planned  for  an  exit  harbor  scenario? 


Health  and  Status 

13.  How  long  does  it  take  to  check  status  of  engine/rudder  (positions,  speed)? 

14.  Can  warning  levels  be  customized  based  on  tolerance? 

15.  How  long  does  it  take  to  determine  trends  in  02  levels?  How  many  people  must  be 
contacted? 

16.  How  are  warnings  given  when  HP  Air  falls  below  a  minimum?  (Is  it  all  or  none,  or  is 
there  an  early  notification?) 
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17.  How  long  and  how  many  people  does  it  take  to  determine  where  munitions  are  on  the 
rack? 

-Is  it  possible  to  determine  the  position  on  the  rack  from  the  bridge? 

18.  How  long  does  it  take  to  determine  what  is  in  each  of  the  torpedo  tubes?  How  many 
people  must  be  contacted? 

19.  How  long  does  it  take  to  check  status  of  systems  to  ensure  readiness  for 
mooring/submerging? 

20.  How  long/what  steps  are  involved  in  figuring  out  the  reliability  of  the  GPS  signal? 

21.  How  long  does  it  take  to  get  an  estimate  of  sonar  range? 
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Appendix  I:  Trust  Questionnaire 


Trust  Analysis 

1.  For  this  svstem,  please  indicate  vour  overall  amount  of  trust. 

1  2 

3  4  5 

No  Trust 

Somewhat  trustworthy 

Complete  Trust 

2.  Please  indicate  the  strength  of  your  feeling  for  the  MSAT  for  each  of  the  factors  by 
circling  the  corresponding  number. 

1.  How  reliable  (in  terms  of  avoiding  obstacles)  is  the  automation  tool? 

1  2  3  4  "  5 

Not  reliable  Reliable 

2.  How  accurate  (in  terms  of  plotting  the  most  efficient  path)  is  the  functioning  of  the 
automated  path  planner? 

1  2  3  4  5 

Not  accurate  Accurate 

3.  Do  you  understand  the  behavior  and  displayed  intent  of  the  automated  path  planner? 

1  2  3  4  5 

Not  Understand  Understand 

4.  How  much  do  you  believe  the  automated  path  planner  in  unknown  situations,  such  as 
choosing  a  path  without  seeing  weather  information? 

1  2  3  4  5 

No  faith  Faith 

5.  How  easy  is  the  automated  path  planner  to  use? 

1  2  3  4  5 


Not  Easy  Very  Easy 

6.  How  robust  (in  terms  of  recovery  from  path  errors)  is  the  automated  path  planner? 

1  2  3  4  5 

Not  robust  Robust 

7.  How  much  do  you  like  the  automated  path  planner? 

1  2  3  4  5 

Dislike  Uike 
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Follow  up  interview  questions 

1.  When  using  this  tool,  did  you  focus  on  the  automatic  path  planner  or  the  manual 
mode? 

2.  Did  you  ever  think  about  using  both? 

3.  Did  the  graphs  on  the  right  showing  path  comparisons  prove  useful  for  planning? 

4.  Did  you  ever  check  the  plot  of  an  auto  planned  path  to  check  for  obstacles,  or  did 
you  trust  that  the  path  would  be  acceptable? 

5.  If  you  did  not  trust  the  system,  why  not? 

6.  What  did  you  like  about  the  MSAT? 

7.  What  do  you  dislike  about  the  MSAT? 

8.  What  would  you  change  about  the  MSAT? 

9.  Did  you  enjoy  the  method  of  interaction  with  the  tool? 
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Appendix  J:  Task  Time  Box  Plots 
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Figure  Jl:  Stateroom  to  control  room 


Figure  J2:  Bridge  to  torpedo  room 
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Figure  J3:  Gather  AIS  data 
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Figure  J5:  Sort  contacts  by  CPA 
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Figure  J6:  Change  one  waypoint 
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Figure  J7:  Check  path  parameters 


Figure  J8:  Plot  new  path 


Figure  J9:  Check  engine 
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Figure  J10:  Check  atmosphere 
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Figure  Jll:  Check  weapons  position 
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Appendix  K:  Supporting  Statistics 


Kl:  ANOVA  table  for  distance 


Source 

Type  III  Sum 
of  Squares 

df 

Mean  Square 

F 

Sig. 

Corrected  Model 

21 1  434b 

2 

105.717 

14.622 

.000 

Intercept 

1044.702 

1 

1044.702 

144.493 

.000 

Method 

154.616 

1 

154.616 

21.385 

.000 

Class 

56.818 

1 

56.818 

7.858 

.009 

Error 

209.674 

29 

7.230 

Total 

1465.810 

32 

Corrected  Total 

421.108 

31 

a.  Computed  using  alpha  =  05 

b.  R  Squared  =  .502  (Adjusted  R  Squared  =  .468) 


K2:  ANOVA  table  for  time 


Source 

Type  III  Sum 
ofSquares 

df 

Mean  Square 

F 

Sig. 

Corrected  Model 

1 54799. 090b 

2 

77399.545 

16.933 

.000 

Intercept 

862247.120 

1 

862247.120 

188.635 

.000 

Method 

150865.245 

1 

150865.245 

33.005 

.000 

Class 

3933.845 

1 

3933.845 

.861 

.361 

Error 

132558.690 

29 

4570.989 

Total 

1149604.900 

32 

Corrected  Total 

287357.780 

31 

a.  Computed  using  alpha  =  .05 

b.  R  Squared  =  .539  (Adjusted  R  Squared  =  .507) 


K3:  Risk  correlations 


Factor  Checked  against  Risk 

Spearman  p 

p  value 

Age 

-0.01 

0.99 

Class  (military/civilian) 

0.39 

0.13 

Years  maritime  experience 

-0.23 

0.39 

Years  charting 

0.01 

0.97 

Trust 

-0.34 

0.24 

Reliability 

0.05 

0.85 

Accurateness 

0.03 

0.94 

K4:  Questionnaire  responses  for  each  risk  level 


Risk  Level 

Number  of 
subjects  in  group 

Trust 

Median  Score 

Reliability 
Median  Score 

Accurateness 
Median  Score 

1  (Low) 

4 

4 

4 

4 

2 

3 

3 

4 

4 

3  (Medium) 

2 

2.5 

4.5 

4.5 

4 

2 

3.5 

3.5 

4.5 

5  (High) 

5 

3 

4 

4 
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